Re: when should sends be virtual?

[Guenter Kniesel <Guenter.Kniesel@Informatik.Uni-Bonn.DE>]

<rainer@physik3.gwdg.de> wrote:

  > >> who is the parent of the method?
  > what i meant is:  if some selector is not found in the activation record,
  > which is the object where the lookup will continue (`method parent')?

Page 5 of the Self 3.0 manual says:
"If a slot contains a method...:
 * The method object is cloned, creating a new method activation object...
 * The clone's self parent slot is initialized to the receiver of the message.
 * ..."
So the lookup will continue in the message receiver. In the case of self sends
/ implicit receiver messages this will be the object currently denoted by 
"self". In your next example, "bar" will be executed in the context of "Frank".

  > imagine Frank (object) in some work hierarchy (delegation
  > chain) being asked to foo (receives unary message).  he doesn't know how
  > to foo (lookup failed) and delegates this to his superior Sabine (parent).
  > Sabine knows how to foo (lookup succeeded).  she gets the scrap of paper
  > with the instructions (code) and follows them: the first line says
  > "bar!" (exclamation point instead of full stop used for clarity)
  > aha, this is an instruction for herself (huh?). END OF STORY
  > 
  > in self as it is, this is to say that message bar is to be sent to implicit
  > self.  but now, who should execute these instructions?  Sabine?  or should
  > she lend that scrap of paper to Frank so he may do what he was asked to do?

Neither one. If you prefer to talk in metaphors, then my understanding is that 
the (clone of the) scrap of paper will execute the instructions. 
But it will not do it on his own - e.g. it will look at how Frank would "bar". 

  > then what does delegation mean, actually?  in the `real' world, `to
  > delegate' surely means to have the other guy actually do it, not just tell
  > one how to do it.  mommy, i don't know how to do this, will you do it for
  > me, please?  this is what a naive observer would expect self to work like.

In my understanding, the mommy example is not delegation but simply asking for
help. Whatever you asked from her, your mommy will do it _as SHE knows best_. 
The best intuitive explanation of (object-oriented) delegation that I found
until now is that 
when I delegate a task to someone, I expect her to do something _on my behalf_
that is, I expect that SHE does it MY WAY. 
So regardless whether Sabine or the scrap of paper executes "bar" they should
do it the same way as Frank would. For that, they need to check what Frank 
would do. That's exactly what is achieved by SELF.  

  > to summarize once again:
  > the decision whether a send should be virtual
  > should be made at the send site.  maybe this demands having two of these
  > global object-references, `holder' and `receiver of last message to non-self'.
  > as i see it, what we mean by `holder' is closer to the common-sense meaning
  > of `self' than what `self' currently means in Self (sic!).
   
As a student I worked in an ESPRIT I project called EPSILON, which implemented 
a knowledge representation framework that extended logic programming with some
object-oriented concepts. EPSILON allowed different kinds of object-based 
inheritance. The most primitive one was called "consultance" 
(in the vein of the previous example we could also call it "ask for help") 
and its semantics was simply that messages, m, that had no local definition 
where automatically resent to a parent object, p, that posessed a definition. 
The resent message was then solved in the context of that parent. 
Put more technically, 
following "consultance" links changed the self variable, such that 
subsequent sends to self during the execution of m where directed to p.

You seem to suggest a more fine grained version of this concept, that allows
to specify at every send site whether "self" should be reset to the parent 
in which the lookup was successful. So "self m" (resp. "m") does not change self,
whereas "holder m" starts the lookup for m in the current self object 
but changes self to the object in which the lookup was successful 
(before executing the found code).

Guenter.