Re: when should sends be virtual?

[Randall.Smith@Eng.Sun.COM (Randy Smith)]

> i am wondering whether there are any "fundamental" arguments in
> favor of or against the convention in self that all sends to self
> are 'virtual' by default.
> 
> what i mean is this:
> 
> imagine object x receives message foo and the lookup finds a
> corresponding method in ancestor y.  now this method foo sends the
> message bar to self.  who is self, where does the lookup start
> (after searching the local (method) slots), who is the pareent of
> the method?  this is a question, i am unable to determine that
> decidedly from the manuals, i can't run self here.
> 
> i call the send 'virtual' when the lookup starts in x, being the
> receiver of the last non-self send (e.g. foo).  this is the default
> with self, right?
> 

That is correct (assuming I understand what you are saying)

> and it is 'non-virtual' when lookup starts in y, being the holder of
> bar.  in self, this is called an 'undirected resend'.
> 
> since one can always deliberately decide which way to use, it might
> just be a matter of convenience which way is to be the default.  but
> it might be a matter of good programming style as well: shouldn't it
> always have to be made explicit when the result of a lookup cannot
> be determined by the sender?  dynamic inheritance set aside, a
> method 'knows' the behavior (of its ancestors) it can rely on when
> doing a non-virtual send.  it seems like good style to me to make it
> explicit when one relies on things that are uncertain.
> 
> making non-virtual sends the default would also give an easy answer
> for a question discussed here some weeks ago:  how to determine what
> behavior some objects rely on their childs to supply it.  simply
> look for virtual sends instead of having to check whether a send to
> self is already implemented in the object or its ancestors.
> 
> there are more possibilities, but only for statically compiled
> languages, i think: actually, one might not be able to deliberately
> decide which way to use because it has been defined one way at the
> time of class-declaration.  this is the case with c++ for example.
> 
> did anybody ever see a treatise about where and when it should be
> specified that a message send should be virtual?  at the send site?
> or at the declaration/implementation of a method?
> ever seen one of these answered?
> 
> greetings,		rainer
> 


Thanks for an interesting question! I have had similar discussions
before though only briefly. I underatnd some of the motivation or making
"non-virtuals" the default. Here is what we were thinking in the
original design of Self:

We were trying to support maximum flexibility. Why would you want to say
to a child "you cannot specialize the use of 'foo' in this method, even
if you want to"?  So we used "full virtuals" for everything we could.

If we could trust the method designer to know best and for all time that
something should never be specialized, then using non-virtuals by
default might make sense. My belief is that such trust is unwise. Most
created things can satisfy more than their creator's original goals.

     --Randy