[self-interest] Re: Delegation and Self like things for Squeak

[Jecel Assumpcao Jr]

On Wednesday 22 August 2001 09:19,  Stephen Pair wrote:
> I thought that a resend in Self has a special syntax like "parent
> resend.someMessage" or something...is that not correct?  In Squeak it
> would have to be "self parent resend.someMessage" or something along
> those lines.  Right now, you can do "self parent delegate:
> #someMessage" ...if your parent implements #delegate:.  I'm going to
> avoid getting into the syntax issues for right now.

Right! I was thinking about all messages to an object with automatic 
"delegation" and you were thinking about explicit delegation. The 
syntax is

                  resend.someMessage: arg

when you want to have the lookup in all parents (so this would be sort 
of like super in Smalltalk) and

                 parentName.someMessage: arg

when you want to restrict the search to a particular parent. I am not 
very fond of this syntax, specially since it makes "." do tripple duty 
(statement separator, resend and floating point).

> > I don't see anyway around this short of a total retrofit of Squeak,
> > which isn't your objective, right?
>
> Well...actually, that's not out of the question...one could retrofit
> the Squeak object format such that any object in the system can pick
> up new behavior (the current Squeak object format would be nearly
> identical to an optimized format in which an object has no unique
> behavior, and only one parent slot).  Only a few bytecodes and
> primitives would need to change.

Ok. And it is certainly possible to run Squeak on top of Self like 
Mario did with GNU Smalltalk. I have been looking into this...

> But, what I really need is a good (and easy) persistence mechanism
> for Squeak...which is what started me on this path (I needed a way to
> quickly bring in external objects, and become was not viable due to
> the lack of an object table...it worked out that delegation was the
> only clean solution).  However, now that I understand a little more
> about the Squeak VM from implementing delegation...I think I may have
> a shot at implementing a virtual object memory for Squeak (instead of
> an external persistence mapping...thus eliminating the original
> motivation for the delegation stuff I just did).

I mentioned on the Squeak list some designs I have considered over the 
years for this. I don't think a consumer quality system is possible 
without it. Things are simply not automatic enough.

> I would like to see both things...a virtual object memory, and the
> ability to completely tailor the behavior of any specific object.
> Then I think multi-user capability would be within grasp (reflection
> primitives could be secured based on the active user, compiled
> methods could be secured with additional security information on the
> object in which it is to execute, etc).  All of this could tie into
> SqueakNOS.
>
> ....well, one has to have dreams.  :)

They are best when they are shared.
-- Jecel