Re: Can MI be supported? (Was: Is the Writing on the Wall for Ada?)

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Dmitry A. Kazakov wrote:
> On Wed, 10 Sep 2003 19:47:46 GMT, "Robert I. Eachus"
> <rieachus@attbi.com> wrote:
>>Hyman Rosen wrote:
...
>>Notice that if I do interface inheritance from the two concrete types, I 
>>can program the underlying routines to do something sensible when say 
>>adding a polar displacement to a cartesian point.  By the way, notice 
>>that in Ada if I want I can provide a type with both cartesian and polar 
>>implementations.  As a programmer, I can go further and add the 
>>"missing" operations like adding a cartesian point to a polar point.  Do 
>>everything right and "+" will just work.  That is a kind of multiple 
>>implementations of a type that I can live with, and I don't know of any 
>>other language where you can do such overloading.  (It is tricky enough 
>>to get right in Ada...)
> 
> It is a good example and it shows that there should be both
> implementation and interface inheritance. Then for interface
> inheritance, it should be possible to inherit from concrete
> (non-abstract) types.
> 
> In the case of multiple views on the SAME point object, it is clear
> that implementation x 2 inheritance would be a wrong solution, because
> it would define a 4D point! A right solution is either:
> 
> 1. implementation inheritance from either Cartesian or Polar point and
> interface inheritance from another.
> 
> 2. interface inheritance from both.
> 
> But this does not prove that multiple implementation inheritance has
> no place.

I have tried to stay out of this fray, and probably should ;-)

But I would add that it doesn't really matter that the MI example
makes no sense, or is poor design. I think what is being suggested
is that the language should allow the programmer to model anything
he can conceive of - even poorly formulated models!


The whole crux of the MI issue is about resolving the clashes of
method and attribute names that MI provokes (or leads to the
possibility of). Certainly, eliminating MI is one way to solve
the problem! Interfaces is another way to hand-wire it
for yourself (ie. working around the problem).

But I can't help but think that MI is "usable" with the correct
amount of care given to it.

Other language(s) allow you special syntax to either:

  - resolve the ambiguity in the declaration
    and
  - resolve the ambiguity in the reference(s)
    (methods and attributes)

I have forgotten the specific language(s) that make
these allowances.  Was it Eiffle?  No matter..


What follows is _just_ discussion, _NOT_ a proposal 8-)  so
don't flame me and the group for its ugliness ;-)


One conceptually ugly way to handle a given MI clash,
is to number them (the inherited from objects).  In
fact, I am sure that many have suggested something
along this line before.... Someone
said something earlier about couching the MI members in
records for example: but take that idea and reference them
by number (for this discussion): 1, for the first inherited
object, 2 for the next etc.  Methods could work along the
same idea.

Again, I am not in favour of using numbers in real
programs for all of the obvious reasons, so just bear with
me here, for discussion's sake.

Once this is done, then clashing members (attributes) and
methods can be qualified in the new objects internals and for
general applicatoin use (let's call these "MI qualifiers"):

    -- Inside some method of Combo_Point which inherits from
    -- a cartesian point and a polar point object:

    1:X := 0;
    2:R := 0;

Object methods could be resolved (in an ugly fashion) as follows:

    procedure My_App
       P : Combo_Point;
    begin
       1:Set_Point(P,New_X,New_Y);


OK, what was my point?  Well all of this is very ugly for
obvious reasons, but the point is that if the ambiguity
for MI is resolved, the whole MI issue goes away. Unless
perhaps I am missing some other related issues like
converting a MI object down to some base class (but again,
the proper qualifiers should be able to help).

You could say that the "MI qualifier" is
unnecessary when no conflicts occur. Certainly
the compiler would be capable of making that determination.
Under those circumstances you could say that this "MI qualification"
then would be illegal. This of course breaks badly, if in
the future a conflict is introduced due to a design change,
causing all clients of the objects to fail to compile
(but maybe that's a good thing?)

In conflicting cases, the compiler would have to insist that
you use "MI qualification" (in whatever elegant form that
someone can come up with -- here we used numbering only
for illustration purposes).

CONCLUSION:

In any case, I think MI _CAN_ be supported, where someone
were to address the "MI qualification" issue in a way that
can be agreed to.

Did I miss other problem(s) with MI that qualification
would not be able to solve? Perhaps there are some
problems within the Ada framework that I have not
anticipated here.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg