[self-interest] A question about Self encapsulation

Jecel Assumpcao Jr jecel at merlintec.com
Thu Dec 17 18:45:58 UTC 2009

Takuro Ikejiri wrote:

> according to this page,
> "The distinction between public and private is purely for documentation.
> Earlier versions of Self enforced privacy (allowing only sends to self
> to locate private slots) but this scheme was found to be unworkable."
> My question is "what is unworkable about Self encapsulation ?".

There was a package of features in Self 1 and 2 that were removed from
Self 3. They were:
- slot privacy declaration
- parent priority
- the "tie breaker" rule

With parent priorities, inheritance could be used for such things as
local name spaces for an object's slots and controlled multiple
inheritance. With lots of small objects in a complex inheriantce graph,
the tie breaker rule was needed to keep the number of conflicts that had
to be manually solved by reorganizing the code as small as possible. The
privacy declarations fit in very well with the scheme, though as Russell
has pointed out they weren't much of a security feature.

As programs grew it became more common for these features to cause a
different slot to be found by the lookup algorithm than what the
programmer expected. For Self 3 a far simpler scheme was adopted: all
parents with the same priority with multiple inheritance used in very
limitd ways and object annotations added to provide namespaces within
objects. It would have been possible to keep enforcing the privacy
declarations even with these changes but it was decided that they were
probably not the best solution and so the problem should be postponed
until a good solution could be found. They were kept as part of the
syntax and were reflected in the new GUI (public slots have bold names).

A variation of Self with subjective programming, called "Us", was
designed and a crude prototype was implemented in Self. That was
considered to be the proper solution to object encapsulation:


> I also read  a paper ( parents are shared parts of objects:
> Inheritance and encapsulation in SELF,1991),
> and learned about inheritance-based encapsulation.
> I think this approach is not good because an encapsulated module
> cannot prohibit access from outside
> (because an object gain access to the module by becoming a child of
> the module).

That paper talks about Self 1. The problem you describe is very serious
and couldn't be solved by just patching the original model. Self 3
wasn't a solution, but like I said above just a "rip out what didn't
work out so well until we can think of something that will work" kind of
thing. Us was the solution, but it isn't available so we are stuck in
the Self 3 model for now.

-- Jecel

More information about the Self-interest mailing list