Re: OOD, Ada, and Inheritance

[sun-barr!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!darwin.sura.net! spool.mu.edu!hri.com!noc.near.net!inmet!spock!stt@decwrl.dec.com (Tucker Taft)]

In article <1992Nov10.205810.5516@mcc.com> 
 breland@cobweb.mcc.com (Mark Breland) writes:

>In article <BxGpxt.FDw@cs.uiuc.edu> johnson@cs.uiuc.edu (Ralph Johnson) writes
:
>>
>>Just as serious a problem with Rosen's paper is the opinion that
>>polymorphism is optional and can be done by hand when needed.  ...
>>                           ...
>>...  Rosen seemed to contradict himself when he
>>talked about why Ada 9X wanted to add support for polymorphism, so
>>perhaps he doesn't really believe this, but was just trying to explain
>>why Ada was designed the way it was.  ...
>
>I saw no contradiction in Rosen's presentation of Ada 9X run-time
>polymorphism.  Rather, it appeared to me he stressed the flexibility
>of Ada 9X to allow *either* explicitly coded compile-time polymorphism
>*or* dynamic binding through tagged types.  Either mechanism may apply,
>at the whim of the initial designer.  See "Ada 9X: A Technical Summary"
>by S. Tucker Taft, also in Comms. of the ACM Nov92, for a detailed
>example of both paradigms.

Speaking for myself ;-), J. P. Rosen's views are somewhat different
from those of the Ada 9X Mapping/Revision Team.  We do believe
that inheritance with type extension and run-time polymorphism are
important additional capabilities, and in fact are more type safe
than the typical equivalent code based on variant records and
case statements.  And of course, the dynamic binding inherent
in run-time polymorphism opens up whole new ways of partitioning
a system into independent subsystems while still retaining type safety.
Since reusable and relatively independent subsystems are critical
to the productive construction of large systems, dynamic binding (run-time
polymorphism) is itself critical to this process.

And since most type-safe dynamic binding is based on the commonality
ensured through the rules of inheritance (at least of interface), 
the two are inseparable in most OOPLs.

>>. . . (Or inheritance is an addition to composition,
>>since composition was first.)
>
>Thank you for stating the above...that's the first time I have heard a
>staunch OO persona give credit to the evolution of object-oriented
>methods, rather than describe it as a radically new invention.

We also believe that object-oriented approaches are a natural
outgrowth of earlier work, in particular abstract-data-type (ADT)-oriented 
approaches.  The big thing that OO brings is robust support
for abstractions with *multiple* implementations.  Although the
concept of multiple implementations of a given abstract data type
was always discussed in academic circles, pre-OO languages with
abstract data types rarely had good support for multiple implementations.

Inheritance and run-time polymorphism make multiple implementations
for a given abstraction practical and workable, allowing code
to be written that works on any derivative of a given type just
as well as it works on the original "root" type of the hierarchy.
The "trick" is that each object carries enough information to identify
its own particular implementation, allowing automatic run-time dispatch
to the "appropriate" implementation of any given "primitive" operation
of the abstraction.  The only thing needed to ensure type safety
is that the operation exists with the given parameter profile;
the actual implementation of the operation need not be known (nor even
exist) at compile-time of the client of the operation.

In other words, the big step from "type-oriented" to "object-oriented"
is not the concept of abstraction, but rather the concept that an
object identifies its own implementation; its compile-time-known
type only identifies its interface.

>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Mark A. Breland             |    Microelectronics and Computer
>  Project Leader - AFT        |    Technology Corporation 
>  (512) 338-3509              |    3500 West Balcones Drive
>  breland@mcc.com             |    Austin, Texas 78759-6509
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

S. Tucker Taft     stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138