Re: when should sends be virtual?

[urs@cs.ucsb.edu (Urs Hoelzle)]

Rainer Blome writes:

> but if y holds methods foo and frob, and the programmer wants to invoke
> frob from foo and is sure that she wants the frob in y and nowhere else,
> she can't enforce it in self!

That is exactly true.  There is no such thing as a procedure call in
Self. 

Why do you make a distinction between self sends and sends to other
objects?  Why should foo rely on the *implementation* of frob rather
than on the semantics of the operation?  If you replaced frob in a
subclass with a behaviorally equivalent version, foo would work fine,
wouldn't it?

>   when all sends have virtual semantics, the author of a descendant has to
> take care to not accidentally override ANY of the possibly large number of
> selectors that its ancestors implement and use (she may of course
> deliberately do so).

Sure, nobody claimed otherwise - in fact, there are many other
dependencies between subclasses and their superclasses (see Alan
Snyder's classical paper for details).  In the end it's a tradeoff
between encapsulation and reusability/fleixbility, and Self comes down
on one side whereas others (e.g., Beta) lean more towards the other.
There is no one true way to resolve this dilemma.

> another aspect of virtual methods being the default is speed.  considering
> this, i don't understand why it is as it is when one of the original design
> goals was speed.  (question: how efficient are resends?  less than
> self-sends when self is the holder?)  

With customization, implicit-self sends are of identical speed whether
they are dispatched or not.  In general, efficiency is not determined
by dispatch speed but by many other factors.  (BTW, speed wasn't one
of the original design goals.)

-Urs