From: stt@spock.camb.inmet.com (Tucker Taft)
Newsgroups: comp.lang.ada
Subject: Re: Ada 9x Dispatching Question
Keywords: Ada Dispatching Polymorphism
Date: 25 Aug 92 16:05:40 GMT
Organization: Intermetrics Inc, Cambridge MA

In article <9223503.26777@mulga.cs.mu.OZ.AU> 
fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

>stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>>In article <9223120.6784@mulga.cs.mu.OZ.AU> 
>>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>
>>>bwhite@cobra.camb.inmet.com (Bill White) writes:
>>>
>>>>Tucker believes that
>>>>it is important to have a syntactic marker to tell when a call is
>>>>dispatching.  An alternative rule would be the C++ rule, where all
>>>>dispatching operations dispatch always.  (Ada9X dispatching operations
>>>>are roughly equivalent to C++ virtual operations.)  This means that the 
>>>>compiler could not replace a dispatching call with a non-dispatching
>>>>call even if the compiler knows where the routine is going to go
>>>>anyway.  This is considered expensive.
>[...]
>>The Ada 9X approach is consistent with the way derived types
>>work in Ada 83, with the addition of the "class-wide" alternative.
>
>So am I correct in understanding that the reason for having the syntactic
>marker is to maintain consistency with the rest of the language, rather
>than because the alternative are "considered expensive"?

The real question is what should be the default, static
binding or dynamic re-dispatch.  We have chosen to make the
default static binding, which is consistent with the way
derived types work in Ada 83.  Certainly dynamic re-dispatch
incurs a little more overhead at run-time, but the main reason
for choosing static binding as the default was really somewhat different.

Imagine you are trying to reuse a type by inheriting from
it, and some of its primitive operations work "just right" while others
you want to change somewhat.  If in fact one of the primitive
operations that works "just right" actually uses dynamic
redispatch to one of the operations that you want to change,
then it will likely no longer work "just right" when you
are through.  Therefore, we felt that dynamic redispatch
must be seen as part of the *interface* to a primitive operation.
That is, it is important to visibly define the functionality of
such and operation as being defined in terms of some other operation.  

Let's take a simple example:

    Presume we have some abstract numeric type, with
    two primitive operations:

       procedure Display(X : Number; R : Radix := 10);
         -- Produces XXXX if R = 10, and R#XXXX# if R /= 10
       procedure Display_In_Hex(X : Number);
         -- Produces 16#XXXX#

Now it is not clear from looking at these whether they
are implemented independently, or whether one calls the other.
Now suppose you like the way that Display works, but you
want Display_In_Hex to produce the hex value without the surrounding
"16#" ... "#" stuff.  So you happily inherit from this Number
type, and override the Display_In_Hex operation.
Unfortunately, you discover later that the "Display" operation is
now producing a different result when given a Radix of 16, namely
that produced by Display_In_Hex.  Apparently Display dynamically
redispatches to Display_In_Hex when Radix = 16.

Of course, the opposite situation might also apply.  You *want*
both Display and Display_In_Hex to start showing hex values
without the 16#...# stuff, and wouldn't it be nice if you
only had to override one of them.

In either case, the fact that one is implemented by a dynamic
redispatch to the other should be included in the interface specification.
Because of that, we feel that it is reasonable that a dynamic
redispatch requires a little more (visible) effort.

You might want to try to find an interesting article by DeWayne
Perry in an old issue of JOOP (I am afraid I have lost the
full reference -- perhaps some other newsey remembers?) that 
described the issue of testing a system built using inheritance.  
The problem of dynamic redispatch can make testing much more 
challenging.  This observation seems to add support to the
idea that dynamic redispatch should be easily visible in the source.

>Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
>This .signature VIRUS is a self-referential statement that is true - but 
>you will only be able to consistently believe it if you copy it to your own
>.signature file!

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138
Newsgroups: comp.lang.ada