consistency again ( was: Notation for delegation in OMT or BOOCH )

[jecel@lsi.usp.br (Jecel Mattos de Assumpcao Jr.)]

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