Re: Does Ada really need MULTIPLE inheritance?

[chase@Ozona.orc.olivetti.com (David Chase)]

I'm not well-versed in Ada, but people I've talked to ensure me that
Ada has something similar to the "opaque types" of Modula-2 and
Modula-3.  Combining opaque types and multiple inheritance can lead to
some nasty problems.  I don't have a solution; just a problem.

I'm assuming that by "multiple inheritance", the people discussing it
means the ability to (1) extend an existing type or (2) refine an
abstract (virtual, in the C++ lingo) type.  In the first case one
might specialize "vehicle" into "car" and "truck"; in the second case,
one might provide a method for "compare" for an abstract "Comparable",
and take advantage of all the code already written to deal with
Comparable objects.

It's the second case, and overriding of existing message-method
bindings in general, that causes the problem.

Suppose I have a type T1, and it has a binding message-method binding
M1-m1a (M1 is the message, m1a is the method for it).  Supposing I
have a type T2 which inherits from T1, and uses the M1-m1a binding.

  T1 = OBJECT METHODS M1() := m1a END;

 T2 = T1 OBJECT METHODS ... END;

Now suppose I export T2 opaquely, along with a procedure P2 which does
something useful with a T2.

 OPAQUE OBJECT T2; (* I'm making up syntax as I go along *)
 PROCEDURE P2(x:T2) ...;

Now suppose I have a type T3 which inherits from T2, and also inherits
from T1, but uses the message-method binding M1-m1b.  I claim that (1)
this should be legal, because the programmer has no way of knowing
that it should be illegal (information hiding, right?) (2) An object O
of type T3 should have the binding M1-m1b where it is visible that O
is a T3 (because that's what the programmer said) (3) An object O of
type T3 should have the binding M1-m1a whenever it is in a context
where it is known to be a T2, but not known to be a T3 (because the
programmer should not be able to invalidate the correctness of a
module if the internals of the module are hidden).

That is (elaborating (3)) if P2 is called, then within P2 the binding
should be M1-m1a, and if O.M1 is sent in that context, then within the
code for m1a the binding should still be M1-m1a.  That is, a second
time, changes to the method bindings for T1 by a subtype T3 *must not*
change the behavior of T3 when considered as a T2; any proofs about
the behavior of a T2 would thus go out the window (and the programmer
would be clueless, because the dependence of T2 on T1's message-method
bindings is hidden).

 T3 = T1, T2 OBJECT METHODS M1 := m2b END;

at some point in the program,

 VAR x : T3;
 ...
 P2(x); (* x MUST act as a T2 in P2, including the binding of
           M1 to m1a. *)
 ...
 x.M1() (* This MUST call method m1b, not m1a. *)

I am *not* arguing that this should be the case if T2 is not opaque;
in that case everything is in the clear, and either an error message
or a change in T2's behavior is allowed.  This nasty situation could
be avoided by creative prohibition (objects cannot be opaquely
exported -- yuck; opaque types cannot be inherited -- yuck; no
multiple inheritance -- many people say yuck, but that's what we live
with in Modula-3), but I'd be even happier if I could figure it out.

David