From: wtwolfe@hubcap.clemson.edu (Bill Wolfe)
Subject: Ada 83, Classes, & Inheritance
Date: 30 Oct 89 03:01:20 GMT [thread overview]
Message-ID: <6902@hubcap.clemson.edu> (raw)
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
reply other threads:[~1989-10-30 3:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox