Re: How to test object hierarchy

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Robert I. Eachus wrote:

> Dmitry A. Kazakov wrote:
> 
>> This is an argument in favor of implementing MD in Ada, I suppose (:-))
> 
> No, it is an argument that current Ada rules are just fine.  You can do
> multiple dispatching in Ada, and the sort of casual dispatching where
> the author of the code doesn't even know that multiple dispatch is
> involves works just fine.  For example, instantiate a generic with a
> classwide type or two as an actual type parameter.  The resulting
> executable may have nested dispatching, but there is no real need to
> anticipate that case when writing the generic.

These cases are not cases of MD. Anything that can be written using
"cascading" dispatch is in fact single dispatch in one argument and
class-wide in another. What is not MD, is not.

> As for cases where you really NEED to understand the code in multiple
> dispatching terms, these are no harder to program in Ada than in other
> languages--and no easier.  And they really are that hard to wrap the
> mind around.  There are cases which are worth the effort, but precious
> few.

The point is that MD is a *natural* view on any subprogam having many
parameters. All other views are in fact kludges, hard to understand and
very error-prone. Note that if the language is aware of MD, it can enforce
necessary overridings, because it knows that they should be. Otherwise, a
developer is exposed to a geometric explosion of variants, which he might
be even unaware of, especially if he derives from a library type.

> Another more prosaic example would be a general graphic file format
> converter.  I can design such a tool as a combination of a reader and a
> writer with a standard intermediate representation:
> 
> ...
> declare
>    Temp: Intermediate_Format := Read(Input_File);
> begin
>    Write(Temp, Output_File);
> end;
> 
> Of course I can rewrite this as:
> 
> Write(Read(Input_File), Output_File);
> 
> Later I might want to add a graphics format that doesn't work well with
> the "standard" intermediate format.  To do this, I can restructure the
> existing code with a multiple dispatch format:
> 
> procedure Process(Input: in Graphics_Format; out Graphics_Format'Class);
>    or
> function Process(Input: Graphics_Format) return Graphics_Format'Class;
> 
> Now I can provide a body which normally uses the old approach with
> Intermediate_Format, but first checks for the special cases and handles
> them with other routines.
> 
> THAT is when it starts to get difficult to use multiple dispatch.  It is
> not the process of doing what I call 'casual' multiple dispatch in Ada,
> that is easy.  The problem is going through on an N**2 case by case
> basis (or N**3 or N*M or whatever) and insuring that the approach that
> is dynamically selected for that particular case is, in some sense, the
> right one.  And when the set of possibilities grows, adding one new
> format means considering 2N-1 new cases.

Right, therefore it has to be supported by the compiler! And in this case,
MD on same type hierarchy, it is pretty easy to do. The compiler shall
simply check that if one of 2N-1 possible overridings happens, others have
to be explicitly overridden too. Also I really wish some language support
for commutative operations, which would reduce the number of variants in
twice.

But the real problem with MD is the case of different type hierarchies. For
example, stream attributes. Present implementation is obviously
inconsistent. S'Write should know all stream types because it is class-wide
in the Stream argument. How a developer of a type can foresee all possible
streams? What if it is a library type? It is clear to me that consistency
should be enforced by the language. The great problem is how.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de