[self-interest] Improvements to Self?

Jecel Assumpcao Jr jecel at merlintec.com
Thu Aug 23 01:02:53 UTC 2001

Better late than never, I suppose...

On Tuesday 14 August 2001 20:47, Ian Woollard wrote:
> > Indeed, I was just wondering what your ":" brought us that we
> > didn't have with Self's "<-".
> Several things-
> a) it can be used for privacy- by inheriting the handle object
> appropriately you can add checking into the object so that it
> only allows certain objects to talk to it.


> b) non builtin syntax can be added to the handle object like:
> c++.
> c += 5.
> etc.
> Also, reference semantics are useful in their own right.

Hmmmm... this seems to me like the opposite of a). Here you are 
exposing things that would be better handled internally. Don't forget 
that Alan Kay started OOP (sorry Simula fans!) because he felt 
assignments were too low level to capture what was going on in the 

> Yeah. Its just sensible- I'd already worked it out I guess, I was
> just confused by the way it was explained in the User Guide. In a
> real sense Self doesn't HAVE lexical scoping; and doesn't need it-
> it's all just syntactic sugar.

True - the "contexts are cloned method objects" story feels much closer 
to the dynamic scoping used in older Lisps. Most people can't tell the 
difference, though this seems to be causing a lot of problems in newer 
languages like Python.

> > But sometimes that is exactly what you want to do. So you would
> > need:
> >
> >   - public slots
> >   - private inheritable slots
> >   - totally private slots
> Not clear why I would want private inheritable slots. Inheriting up
> might be ok, but inheriting down; never. If I really want that then
> I can add a separate public slot that can work out whether an object
> is worthy of accessing the private slots.

I am not sure what you mean by "up" and "down".

Is "up" when object A runs method X actually found in parent B and X 
sends a self message Y that is a private method in A?

And is "down" when object A runs local method X and sends a self 
message Y that is a private method in parent B?

Neither seems absolutely evil to me, though I would like control over 
these situations.

> > Otherwise any public method that called a private one would break
> > when invoked by a child object that didn't reimplement the private
> > one.
> That could be allowed I think- only when 'self' contains the private
> slot, and the sender was self is it allowed. Something like that.

In my example 'self' didn't contain the private slot - its parent did. 
It is a third case, not either down nor up from above (though it is 
pretty close to "down").

-- Jecel

More information about the Self-interest mailing list