wtwolfe@hubcap.clemson.edu (Bill Wolfe) (10/30/89)
Ben Brosgol, Vice President of Alsys, has recently written in Alsynews (a free publication of Alsys, Inc.) regarding the reasons Jean Ichbiah (Alsys Founder & CEO, and leader of the Ada 83 design team) did not provide more direct support for object-oriented programming in Ada 83: [...] Jean Ichbiah, the principal designer of Ada, worked on one of the first implementations of Simula-67. He was well aware of the implementation consequences of classes and inheritance, and it was in fact run-time efficiency arguments that dictated against inclusion of these features. To see this, consider the representation of objects at run time. If a class SQUARE inherits from a class POLYGON, any field in a POLYGON must also be in a SQUARE, and thus the representation of a SQUARE must be at least as large as a POLYGON. However, with polymorphism it is possible to assign a SQUARE to a POLYGON. This means either (1) truncating the SQUARE-specific fields; (2) preallocating the maximal amount of space for a POLYGON that will be required for any of its heirs; or (3) using pointers and representing objects indirectly. The first alternative loses information and is not desirable. The second alternative requires a centralized definition of POLYGON; [...] this would defeat some of the purposes of object-oriented programming. Thus the third alternative is adopted in OOLs. Assignment means either pointer copy and object aliasing, or allocation of a copy of the source object for reference by the target. However, once the fateful step of implicit pointers is taken, the implementation cannot ignore the problems of storage reclamation. If garbage collection is used (as in Simula), efficiency and applicability to real-time applications are sacrificed. If garbage collection is not used, then the programmer is left to figure out when objects are no longer referenceable and when they can thus be explicitly deallocated. [...] Since the implicit use of pointers is so unappealing, Ada avoids the problem by not providing the features responsible. Thus Ada [83], lacking some of the run-time flexibility found in OOLs, is not an Object-Oriented Language. On the other hand, what it gains is more static checks (and hence earlier detection of errors) as well as increased efficiency. Which is what is needed to program the class of real-time applications that Ada was designed to handle. Several problems are now apparent in this reasoning. First, it is necessary to isolate the question of multiple inheritance from the question of polymorphism. Multiple inheritance is nothing more than a definitional mechanism, and hence can be completely handled at compile time. Thus run-time efficiency arguments do not apply to this aspect of the problem. Secondly, Ada is not just for real-time users; information systems users are one example of another major group of Ada users (Ada 9X Project Report, January 1989, III.4). Thus Ada 9X must take into account the needs of both real-time and not-necessarily-real-time users. The Classic Ada product (which allows Ada software developers to use inheritance and dynamic binding in object-oriented Ada designs; available from Software Productivity Solutions, Inc. at SPS@radc-softvax.arpa) provides a product feature whereby techniques can be applied to either optimize away the need for or block the use of anything involving significant run-time expense (such as dynamic binding), while still providing the advantages of those capabilities which do not require such costs (such as inheritance). Thus, the path to these capabilities in Ada 9X has already been defined: simply provide a pragma REAL_TIME which will cause the compiler to either generate code which does not expose the user to significant run-time penalties if that is possible, or generate an error message along the lines of "Statement is inconsistent with the requirements of pragma REAL_TIME" if not. And finally, significant advances have been made in the realm of real-time garbage collection algorithms, although the problem is not yet completely solved. The provision of object-oriented capabilities in conjunction with pragma REAL_TIME allows compiler vendors to incorporate sophisticated new real-time garbage collection algorithms as soon as they are discovered, and then modify the effect of pragma REAL_TIME such that it does absolutely nothing. In this way, advances in garbage collection technology will enable real-time users to begin using the full range of object-oriented capabilities almost immediately, without obsoleting any of the code written back when the effect of pragma REAL_TIME was much more restrictive. Hence, Ichbiah's rationale for not including classes and inheritance in Ada 83 does not apply to the current Ada community. With further advances in real-time garbage collection technology, the efficiency considerations will not apply to anyone at all. The inclusion of modern object-oriented capabilities in Ada 9X will permit non-real-time users to take advantage of them immediately, and real-time users to take advantage of some of them now and the rest of them as compiler technology permits. It is therefore appropriate that the flexibility and power of the object-oriented paradigm be included in Ada 9X, and I expect that this will indeed be the case. Bill Wolfe, wtwolfe@hubcap.clemson.edu