Delegation and Self like things for Squeak

[Stephen Pair]

--- In self-interest at y..., Jecel Assumpcao Jr <jecel at m...> wrote:
> Stephen,
> 
> great job!
> 
> I think that the missing piece (having the compiler generate the 
new 
> bytecodes) isn't hard to do. 

No, not hard at all...but I'm not overly eager to work on that.

> But you would have to come up with a new 
> syntax to express delegation and making it different from regular 
> message passing would give it a significantly different feel from 
Self. 

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.

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

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 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.  :)

> One suggestion is to add a new keyword "resend" in the spirit 
of "self" 
> and "super". Of course, that might be confusing if a message being 
> resent is found in the object itself.
> 
> -- Jecel

- Stephen