Re: Merits of re-dispatching [LONG]

[Tucker Taft <stt@avercom.net>]

"Dmitry A. Kazakov" wrote:
> 
> Hi!
> 
> C++ and Ada 95 support re-dispatching, which I think is inherently
> unsafe.
> ...

Redispatching is the default in most OO languages.  In some, like
Eiffel and Java, there is no alternative.  In C++, it is possible
to explicitly prevent redispatching by using the :: operator.  By default,
if you use a reference, a pointer (e.g. "this"), or just
the virtual function name by itself, you get (re)dispatching.

In Ada 95, we chose to make static binding the default, with (re)dispatching
happening only when the actual parameter is of the classwide type (T'Class).
This was a conscious decision, and means that places where (re)dispatching
is occurring are visible to the reader, and requires some explicit intent
by the programmer.  This reduces the cases of unintentional redispatching,
and (hopefully) encourages the programmer to mention internal redispatching
as part of the semantics of the operation.

In your example, you have used redispatching in a finalization routine.
As you point out, that is an unusual time to do so, and is probably
unwise, because the descendant's finalization activity has probably already
taken place.  Hence, your example illustrates an inappropriate use
of redispatching.  On the other hand, there are many examples of appropriate
use of redispatching.  However, these all are cases where the semantics
of the routine should be explicitly idenfitied as including redispatching.

For example, consider the following:

    type T is tagged ...
    function Image(X : T) return String;  -- Return string representation of T
    procedure Put(X : T);  -- Display T on standard output; by default,
                           -- put result of (redispatch to) Image function

In this example, we have defined the "default" semantics of "Put" to
be a Text_IO.Put of a redispatching call to Image.  This would allow a programmer
to override Image only, and have the desirable effect of having Put's results altered
as well.  Here is the implementation of this "default" Put:

   procedure Put(X : T) is -- by default, put result of calling Image
   begin
       Text_IO.Put(Image(T'Class(X));
   end Put;

On the other hand, for some complex types, it may be desirable to take advantage
of the fact we are displaying on standard output, and we might create a multi-line,
nicely indented version of the display.  In that case, we would want to override
Put to not simply put out the result of calling Image.

Clearly this relationship between the Image and Put primitive operations
needs to be explicit in the spec for "T".  Otherwise, when we release a new
version, we might choose to change Put to effectively "inline" the semantics
of Image, rather than making a redispatching call.  In that case, the
programmer could choose to inherit the "Put" semantics as is while changing "Image",
but could no longer override only Image and expect Put to change "correspondingly."

This is a fairly simple example, but with a complex type, the relationships
can get very complicated.  If no redispatching is done, then all of the
operations are independent "black boxes," and they can be inherited if they
already have the desired effect, or overridden if they don't.  When redispatching
is present, the programmer needs to know the relationships between the primitive
operations, so they can make appropriate decisions about inheriting versus
overriding.

As mentioned above, in Ada 95, we chose to make static binding the default for calls
from one primitive to the next, thereby providing minimal "coupling" between
the primitives, and allowing them to be reused as black boxes.  However, we
felt it was essential that we also supported explicit redispatching, for the
cases where "pass-the-buck" semantics were appropriate, where by default
one primitive should redispatch to another, allowing a fewer number of primitives to
be overridden when extending a type.

In any case, we agree that redispatching can be the wrong thing to do, and
making it the default opens the door for unintentional coupling between
primitives, effectively requiring that a programmer see the source code
for the primitives of a parent type to determine the effect of overriding
some but not all of the primitives in a derived type.

> ...
> Is there examples where re-dispatching is really unavoidable?

If you are always willing to override all primitive operations, 
then re-dispatching is avoidable.  However, if you want to override
only some of the primitives, and rely on the others being defined
by default in terms of these, you can simplify the job of extending
a type.  But as indicated above, we certainly agree that redispatching
is part of the *visible* semantics of a primitive operation, when extending
a type.
> 
> Regards,
> Dmitry Kazakov

-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Bedford, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)