Delegation and Self like things for Squeak
spair at yahoo.com
Wed Aug 22 13:19:54 UTC 2001
--- In self-interest at y..., Jecel Assumpcao Jr <jecel at m...> wrote:
> great job!
> I think that the missing piece (having the compiler generate the
> 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
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
...well, one has to have dreams. :)
> One suggestion is to add a new keyword "resend" in the spirit
> and "super". Of course, that might be confusing if a message being
> resent is found in the object itself.
> -- Jecel
More information about the Self-interest