[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
consistency again ( was: Notation for delegation in OMT or BOOCH )
- To: email@example.com
- Subject: consistency again ( was: Notation for delegation in OMT or BOOCH )
- From: firstname.lastname@example.org (Jecel Mattos de Assumpcao Jr.)
- Date: Tue, 19 Jul 94 19:11:08 EST
- Reply-to: <email@example.com>
- Resent-date: Tue, 19 Jul 94 15:19:25 PDT
- Resent-from: Urs Hoelzle <urs@otis>
- Resent-message-id: <9407192219.AA04997@otis.Stanford.EDU>
- Resent-to: real-self-interest
firstname.lastname@example.org (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
> 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
This reminded me of:
> Subject: Re: consistency in Self
Randall.Smith@Eng.Sun.COM (Randy Smith) wrote:
> email@example.com 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...