Re: Does Ada really need MULTIPLE inheritance?

[billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )]

From NCOHEN@IBM.COM (Norman H. Cohen):
> Two recent workshops focused on adding support for object-oriented
> programming to Ada.  [...] I do want to mention two areas of consensus
> reached at both workshops:
>    (1) Ada should support inheritance.
>    (2) There is no convincing need for MULTIPLE inheritance.
> Since nobody at either workshop was a strenuous advocate of multiple
> inheritance, I would like to see the argument for multiple inheritance
> presented here.  

    David Eichmann has presented one; a few more appear below.

> Among the thoughts that contributed to the consensus
> AGAINST multiple inheritance were:
> 
>    (1) In many cases, the effect of multiple inheritance could be
>        achieved also by instantiating a generic unit defining a subclass
>        of a class given by a generic parameter.  This allows different
>        classes to be extended in a uniform way.
> 
>    (2) Multiple inheritance may seem essential in some object-oriented
>        languages because inheritance is the only importation mechanism.
>        Ada can get by with a WITH clause in many contexts where other
>        languages use multiple inheritance.  In Eiffel, for example, one
>        inherits from class MATH, which has operations but no state data,
>        to achieve the effect of WITHing a math package in Ada.

   I would submit that the generic mechanism and the multiple inheritance
   mechanism are conceptually orthogonal; trying to use generics to simulate
   multiple inheritance is like trying to simulate recursion with a stack,
   etc.; although it may be possible, its desirability in terms of program
   clarity is highly questionable.
 
>    (3) In some language proposals, multiple inheritance is a natural
>        generalization of single inheritance.  In other proposals,
>        however, multiple inheritance is difficult to accommodate.
>        For example, the view that subclasses should be treated as Ada
>        subtypes has much going for it (for details, see my proposal
>        "Ada Subtypes as Subclasses," Research Report RC14912, which can
>        be obtained by writing to IBM Thomas J. Watson Research Center,
>        Distribution Services F-11 Stormytown, P.O. Box 218, Yorktown
>        Heights, NY 10598), but it is incompatible with multiple
>        inheritance in a strongly typed language like Ada.

   Subclassing and subtyping are two somewhat similar, but distinct 
   concepts; both need to be properly supported.  I see no reason why 
   this could not be accomplished.

>    (4) Many (including Bertrand Meyer) hold that the inheritance
>        hierarchy should reflect an "is-a" relationship.  That is, each
>        instance of a subclass should be an instance of its immediate
>        superclass(es) as well.  There are a few well-known examples
>        where the "is-a" relationship holds with multiple parents (a text
>        window is both a text file and a window, e.g.) but such examples
>        are rare, too rare to justify further complication of the
>        language.

   I would argue first that such examples are not necessarily rare;
   it may simply be that the lack of an ability to express the idea
   at all has greatly restricted the amount of time spent considering
   the possibilities, and that many valid applications of the concept 
   will emerge once its expression becomes possible.  

>    (5) Multiple inheritance makes it difficult to determine the source
>        of a subclass's features, or to determine the impact of changing
>        the interface of a superclass.  It tends to lead to undisciplined
>        software composition that may be fine for exploratory programming
>        but is unacceptable for the huge projects in which Ada is used,
>        projects that require strict configuration management.

   Determining the source of a subclass's operations can be done
   with an appropriate tool automatically.  Determining the impact
   of changing the interface of a superclass is similar to the problem
   of determining the impact of a change to a package interface; when
   the syntactic interface to a package changes, there is a "direct" 
   impact in that certain portions of code (the code withing the 
   modified spec) must be recompiled.  However, this does not bound 
   the *semantic* impact; semantic modifications can be made without
   even causing recompilation, and can propagate throughout the system
   essentially unchecked.  Consider what would happen if something as
   heavily relied upon as a mathematics package were to be semantically
   modified; newly linked programs everywhere could begin to fail through
   absolutely no fault of their own, whether because of subprograms that
   failed catastrophically as a direct result of the modification or 
   because of subprograms that began to deliver subtly incorrect results.

   The only answer to this, I think, would be to incorporate something 
   like Anna/TSL into the definition of Ada, and even then the costs of 
   specifying and enforcing semantics so tightly would be considerable.  
   In short, there's no easy answer, and no escape from the problem.  

   Finally, the point about it tending to lead to undisciplined software
   composition is certainly not without supporting evidence, in that 
   the capability has so far been most extensively used in support of 
   exploratory programming.  But it is not my purpose to enable
   exploratory programming to be done; my objective is to enable the
   natural expression of real-world relationships, and also to enable
   the systematic reuse of concepts which have already been expressed.  

   Perhaps ideas will emerge which will lead to a means of restricting
   undisciplined use of multiple inheritance, just as ideas such as
   doing type-checking and making any arithmetic difficult have 
   successfully restricted the undisciplined use of pointers. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu