Re: Derived private interface

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

On Sat, 23 Jul 2011 00:30:12 -0700, Jeffrey Carter wrote:

> Maybe I'm missing something, but it seems to me that all dispatching in Ada is 
> related to extensions.

Yes, but that is a language design bug (sorry, feature (:-)). There is
nothing in the idea of a class of types which would instruct a derived type
to add new components, and not to discard existing components, or to
provide an absolutely unrelated implementation.

Extension is an invention of lazy language designers.

> type T2 is new T with ...
> 
> overriding procedure P (V : in out T2);
> 
> Then you can get a single call that sometimes calls P for T and other times P 
> for T2; that's dispatching.

No, it always means the *same* primitive operation P defined on the type
T'Class. P for T is defined on T, P for T2 is defined on T2. Neither is
defined on T'Class.

In Ada you always know which operation is to be called.

> I don't know what dispatching means without an 
> extension and an overridden subprogram to dispatch to.

If you mean the implementation of a primitive operation P, then how is it
different from other operations? Ada separates interface and
implementation. You newer know the implementation without looking into the
body(es).

> The equivalent of dispatching in programming by composition is a subprogram that 
> contains a case statement that contains calls to other subprograms. No 
> access-to-subprogram values involved. It does the exact same thing as 
> dispatching, except that it's easier to read and understand and doesn't result 
> in large numbers of "what am I doing wrong?" posts to c.l.a.

There is a sufficient difference. The case statement needs an enumeration
type (a substitute for the tag type) which should be declared in advance to
all future implementations. This means that you have to know all derived
types at a very early stage of the project. Certainly you don't want
"others =>" in that statement. Furthermore the procedure must "with" all
implementations of all derived types. Now you have:

1. Problems with maintenance (fixing the statement and with clauses)

2. You have to ensure the correspondence between the values of the
enumeration type and the procedures called in "when This => That (X);". The
language cannot help you here.

3. Potential problems with elaboration order (inversed, mutual
dependencies).

4. Lack of static check if each "derived" type has a defined body.

5. Lack of abstract types. An abstract type has no instances, but may have
implementations. I.e. it appear in the switch. But you cannot compose
abstract components. Once abstract always abstract.

And finally, it does not change anything semantically. Whatever problem
(substitutability issues / LSP) the programmer might have with tagged
types, he will under composition.

> In Ada, "programming by extension" is achieved by the use of tagged types; it 
> includes dispatching. I have never seen anything implemented using tagged types 
> that could not also be implemented using programming by composition. It follows 
> that if there is a case where tagged types cause a problem, the equivalent 
> solution without tagged types is an effective work around to the problem.
> 
> Of course, in the case where there is no solution using tagged types, there may 
> also be no solution without using them.

An argument to Turing-completeness? (:-))

Compare: I never saw anything written in Ada, that could not be implemented
in Assembler...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de