[self-interest] A question about Self encapsulation

Russell Allen mail at russell-allen.com
Fri Dec 18 00:56:47 UTC 2009


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 at 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



More information about the Self-interest mailing list