From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 11 Nov 92 04:20:43 GMT From: 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) Subject: Re: OOD, Ada, and Inheritance Message-ID: <1992Nov11.042043.9740@inmet.camb.inmet.com> List-Id: In article <1992Nov10.205810.5516@mcc.com> breland@cobweb.mcc.com (Mark Breland) writes: >In article 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