I haven't tried it, but if the availability of mirrors could be restricted then objects should be able to protect/encapsulate other objects either by making the slot name something unguessable or by having the object only referred to in a method...

On Thu, 17 Dec 2009 16:45:58 -0200, "Jecel Assumpcao Jr" jecel@merlintec.com wrote:

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:

http://portal.acm.org/citation.cfm?id=246311 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.7535 http://www.mip.sdu.dk/~bnj/library/Us_Ungar.pdf

...

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