mulet@info.emn.fr (Mulet Philippe 40448387) wrote:

I am working on meta-object protocols for controlling and extending the semantics of message passing.

As such, Pierre Cointe and I, defined a prototype-based language, close from Self at first, without any delegation, but supporting a full reflective model. Then, we extend this model only by involving its reflective facilities, so as to provide single delegation, multiple delegation, caches, ... in an incremental way.

If you are interested, I can give you more information,

I found this work very interesting. One of the things I liked most was how message reception was devided into two phases: the lookup where the object ( really the meta-object, but let's ignore that ) decides which of its slots is refered to by the message selector, and the apply where the result of the lookup does something according to its nature.

This reminded me of:

Subject: Re: consistency in Self

Randall.Smith@Eng.Sun.COM (Randy Smith) wrote:

ivan@cs.man.ac.uk wrote:

...

Maybe this is an extreme point of view - but don't you think it's inconsistent that you can't have a parent slot 'implemented' as a method? OK - so it might be a bit slow - you'd have to call the parent slot method(s) for an object for every message it received.

No, I don't think it extreem: it's also bothered me for the very consistency reason that you point out.

Should the method in the parent slot be evaluated when a message lookup has to go through that slot? If so, why? And if so, what if that method sends subsequent messages to self that don't match directly in the receiver? Infinite regress city.

But maybe the method in the parent slot is not evaluated when it is looked up through (new verb form there). If not, why not? And is there some utility to having parent as a message be different from parent used in lookup?

These thoughts have always bogged me down.

From the lookup/apply point of view ( there are certainly others )

the lookup and the "parentness" of a slot are a property of the receiver of the message, while the behaviour of the slot ( if it returns data, assigns to another slot or executes code ) is a property of the slot itself. To execute the slot's code during lookup is to mix things up in a not very useful way.

So whether one way is more consistent or the other depends on your model of how things work.

I would not complicate the implementation for consistency unless there was a real gain. I can imagine some pretty useless stuff ( I suggested method parents about two years ago :-) :

1) parent argument slots - we already have an implcit ":self*" slot in every method. But user definable parent arguments ( how is that for dynamic inheritance :-) would be very dangerous as any method might get inside access to objects passed as arguments to it ( a poor man's multimethod? :-)

2) assignable method slots - we already can assign blocks ( but can't do anything with them ). We can also get close with "sillyParent: ( | x = ( ... ) | )" as an aproximation of an assignable slot "x". And, for the patient, there is always "_AddSlots: ( | x = ( ... ) | )"

3) I'll leave this as an exercise for the readers...

- Jecel