Category : Miscellaneous Language Source Code
Archive   : OOPS.ZIP
Filename : BERARD05.TXT

Subject: Evaluating "Object-Oriented" Programming Languages
Keywords: object-oriented, programming languages, evaluation, bibliography
From: [email protected] (Edward Berard)
Path: haven!purdue!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard
Newsgroups: comp.object
Date: 3 Jan 90 03:18:09 GMT


"Give us the tools, and we will finish the job."

-- Winston Churchill (February 9, 1941)

"We dissect nature along lines laid down by our native
language ... Language is not simply a reporting device for
experience but a defining framework for it."

-- Benjamin Whorf (1897 - 1941) in "Thinking in Primitive
Communities"

PROLOGUE

Object-oriented software engineering (OOSE) is an extremely hot topic.
There is a rapidly-increasing number of books, articles, seminars,
conferences, and products which focus on the technology. Only a few
years ago, the discussion was largely limited to programming language
features. Now, however, software engineers are investigating and using
such things as "object-oriented requirements analysis" (OORA),
"object-oriented design" (OOD), "object-oriented database management
systems" (OODBMS), "object-oriented computer hardware" (OOCH), and
"object-oriented computer aided software engineering" (OO CASE).

The character of object-oriented applications has changed. Originally,
most object-oriented applications were small and non-critical.
Object-oriented software engineering was chiefly experimental, i.e.,
not production-oriented Slow programming language interpreters, highly
non-portable languages and environments, lack of concurrency-related
features, and fairly limited access to low-level machine
characteristics were all tolerable.

Now, object-oriented software engineering is entering the mainstream.
Object-oriented technology must demonstrate its suitability for
applications which are both large and critical. Software engineers
must adapt object-oriented concepts to consider such issues as
efficiency, low-level hardware characteristics, portability, and
concurrency. They must do this in a way which preserves the desirable
features, and the essence, of the object-oriented paradigm.
In each object-oriented application, one of the tools that will have
to be considered is, of course, the implementation language. At one
time, the choice was simple -- there was only one language (i.e.,
Smalltalk) which claimed to be "object-oriented." Now there are scores
of languages, and a plethora of variants, all of which claim to be
object-oriented. The issue is further complicated by those who
advocate the (occasional) use of traditionally "non-object-oriented"
programming languages in object-oriented applications.

HISTORICAL BACKGROUND

In the very early 1970s, things were simple. There was only one
programming language which called itself "object-oriented," i.e.,
Smalltalk ([Goldberg and Robson, 1983]). Further, all that anyone
seemed interested in was "object-oriented programming" (OOP). No one
even suggested such things as "object-oriented design" (OOD) or
"object-oriented requirements analysis" (OORA).

In the 1980s, there was an explosive growth in object-oriented
programming languages. Initially, most of these languages attempted to
define themselves in terms of the Smalltalk paradigm. As our
understanding of object-oriented concepts matured, however, the
deviations from Smalltalk concepts among so-called "object-oriented
programming languages" (OOPL) became more pronounced.

[The 1980s also saw the birth and evolution of OOD, OORA,
object-oriented domain analysis (OODA), and object-oriented database
management systems (OODBMS). As our understanding and usage of OOPLs
increased, so did our understanding of object-oriented software
engineering (OOSE) in general.]

By the late 1980s, there was not only an increased interest in OOPLs,
but also an increased interest in:

- attempts to evaluate, classify, or justify a given
programming language as being "object-oriented," e.g.,
[Bach, 1988], [Buzzard and Mudge, 1985], [Cook, 1986],
[Touati, 1987], and [Wolf, 1989]

- adding, or suggesting, "object-oriented extensions" to
existing programming languages, e.g., [Bergin and
Greenfield, 1988], [Cox, 1986], [Di Maio et al, 1989],
[Donaldson, 1989], [Forestier et al, 1989], [Moon, 1986],
[Simonian and Crone, 1988a], [Simonian and Crone, 1988b],
[Waurzyniak, 1989], and [Wegner, 1983]

- developing applications using an object-oriented approach,
but using traditionally "non-object-oriented," programming
languages, e.g., [Edelson, 1987], [Jacky and Kalet, 1987],
and [Zaniolo, 1984].

All of this has stimulated efforts to define the criteria for calling
a language an object-oriented programming language. For example, Peter
Wegner, in [Wegner, 1986], offered:

"We define 'object-oriented' so that it includes
prototypical object-oriented languages like Smalltalk and
Loops, but excludes languages like Ada, Modula, and Clu which
have data abstractions but are not generally considered
object-oriented. Support of data abstraction is a necessary
but not sufficient condition for a language to be
object-oriented. Object-oriented languages must additionally
support both the management of collections of data
abstractions by requiring data abstractions to have a type,
and the composition of abstract data types through an
inheritance mechanism:

"object-oriented = data abstraction + abstract data types +
type inheritance."

[There have been a number of good overview articles describing the
characteristics found in many different object-oriented programming
languages, e.g. [Stefik and Bobrow, 1985], [Wegner, 1987a], [Wegner,
1987b], and [Wegner, 1989]. The reader should be aware that not all
authors agree on "the basics," and that the technology is constantly
evolving.]

However, there are a good many problems which arise when people
attempt to classify a particular programming language as either
object-oriented or non-object-oriented.

PROBLEMS WITH EVALUATIONS

Some "litmus tests" for object-oriented programming languages are
based on how close a programming language is in concept and
implementation to Smalltalk. There are obvious problems with this
approach, e.g., since a language which is not Smalltalk must differ
from Smalltalk in some (usually significant) ways, what are acceptable
deviations? Further, as we begin to understand more about the
object-oriented paradigm, some people have begun to point out
"deficiencies" in Smalltalk, for example, the lack of type checking
(see, e.g., [Johnson, 1986]). Is a programming language which
"corrects" these deficiencies more object-oriented than even Smalltalk
itself?

A major source of problems in any comparison scheme is the confusion
between concepts and implementations. For example, in Smalltalk,
objects communicate (i.e., work gets done) via "message passing."
Messages are sent from one object to another. CLOS ([Keene, 1989]),
does not have message passing in the Smalltalk sense, but instead uses
a generalization that is more Lisp-like, i.e., generic functions. Is
this an acceptable "deviation?" The important question here is: when
physical differences arise, how great must these differences be before
"reasonable people" can agree that the differences are not only
physical differences, but also conceptual differences.

The greatest problem is determining just what "object-oriented
characteristics" a programming language must possess to be considered
a "true" OOPL. There are more than a few contenders for
object-oriented programming language characteristics, e.g.:

- Encapsulation: Encapsulation is the localization and binding
together of items. In languages such as Smalltalk, the
encapsulation is physical, i.e., it is accomplished via the
syntax and semantics of the language. For example, Smalltalk
offers a "class" construct which allows a programmer to
physically encapsulate the the methods, operations, and
other features which logically constitute a class.

The Common Lisp Object System (CLOS), on the other hand,
does not provide much physical encapsulation, and instead
emphasizes logical encapsulation. (See, e.g., [Gabriel,
1989] and [Keene, 1989].)

- Information hiding: Information hiding is the suppression of
(hopefully) unnecessary details. Most commonly, the idea is
to reveal details at a given level of abstraction, and to
hide, or cover up, details at lower levels of abstraction.
In Smalltalk, objects are black boxes, i.e., their internal
structures and implementations are hidden from those outside
of the object. (To be technically accurate, they are hidden
from objects which are outside of the object's
subclass-superclass chain.)

C++ ([Stroustrup, 1986]), on the other hand, allows
"violations" of strict information hiding via friend
functions. These functions allow objects to have access to
the internals of other objects. Flavors ([Moon, 1986]) and
LOOPS ([Bobrow, 1983]) allow instances to directly access
the internals of other objects.

- Data abstraction: Data abstraction is a form of abstraction
where the details of the underlying algorithms are hidden
(i.e., they are an abstraction), and the type of data which
those algorithms manipulate is also a high-level concept,
i.e. an abstraction. Data abstraction allows objects to be
treated as black boxes, e.g., "name objects" may be added to
"directory objects" without regard to the underlying
implementation of the name objects. (See, e.g., [Liskov,
1988].) Data abstraction is implemented directly in
languages such as Simula ([Dahl and Nygaard, 1966]),
Smalltalk, Ada, Modula ([Wirth, 1983]), and Clu ([Liskov et
al, 1977]), but is not directly available in common
programming languages, e.g., C, Pascal, Fortran, and Cobol.

Data abstraction is also necessary for the implementation of
metaclasses. A metaclass is a class whose instances are
themselves classes. Some object-oriented programming
languages (e.g., C++ and Trellis ([Schaffert et al, 1986]))
do not allow for straightforward implementation of
user-defined metaclasses.

- Inheritance: Inheritance is a mechanism whereby a subclass
acquires characteristics from its immediate superclass, and,
by induction, from all of its antecedent superclasses.
Inheritance is implemented in a dynamic manner in languages
such as Smalltalk and C++, but may also be accomplished via
other mechanisms, e.g., via preprocessors ([Donaldson,
1989]) or using existing features of a language ([Perez,
1988]). The chief question seems to be: "must a given
programming language implement inheritance in exactly the
same manner as Smalltalk to be considered object-oriented?"

In some "classless" object-oriented languages (e.g., Self
([Unger and Smith, 1987])), mechanisms which differ
(slightly) from inheritance (e.g., delegation) are used.
There have been attempts to reconcile these differing
mechanisms, e.g., the "Treaty of Orlando" ([Lieberman et al,
1988]). There are also extensions of the Smalltalk type of
inheritance. For example, Smalltalk has only single
inheritance (i.e., each subclass has exactly one immediate
superclass), and Eiffel ([Meyer, 1987]) supports multiple
inheritance (i.e., each subclass may have more than one
immediate superclass).

Some have observed that Smalltalk-like inheritance can
mitigate some of the benefits of encapsulation, e.g.,
[Snyder, 1986]. Further, Smalltalk-like inheritance can have
undesirable side-effects when changes are made to the
subclass-superclass hierarchy.

- Classes: A class is an object which is used to create
instances, where an instance is a specific thing or
characteristic. More precisely, a class is a template,
description, pattern, or "blueprint" for a category of very
similar items. Among other things, a class describes the
interface these items will present to the outside world.
Classes first appeared in Simula, and are called "classes"
in languages such as Smalltalk, C++, and Eiffel ([Meyer,
1987]).

Some object-oriented programming languages specifically
avoid classes. For example, David Unger's Self uses no
classes, and creates new objects from existing
(prototypical) objects. Beta ([Kristensen et al, 1987])
"replaces classes, procedures, functions, and types by a
single abstraction mechanism called the pattern." Actor
languages (e.g., [Agha, 1986]) lack both classes and an
inheritance mechanism.
- Types: Whereas a class defines the structure and
characteristics of its instances, a type defines those
operations in which an object may participate, and under
what circumstances the object may legally participate in
those operations. Types are a relatively new concept in
object-oriented programming. Smalltalk has, in effect, no
types, but there are typed extensions to Smalltalk, e.g.,
[Johnson, 1986]. C++ also supports some typing, i.e., more
than C, and much less than Ada ([DoD, 1983]).

- Static Versus Dynamic Binding: Binding is the association of
allowable operands (i.e., objects) with operations. Binding
may be either static (or early), i.e., accomplished at
compile time, or dynamic (or late), i.e., accomplished at
run-time. Until the introduction of Objective-C ([Cox,
1986]), there was little, if any, discussion of "binding"
within the object-oriented community.

Static binding is usually associated with strongly typed
programming languages, and dynamic binding with weakly-typed
programming languages. Smalltalk and Objective-C support
dynamic binding.

- Message passing: In Smalltalk, work is accomplished by
message passing. Messages have a prescribed format, and are
handled in a specified manner. However, Wegner ([Wegner,
1987], page 512) observes: "... the term "message passing"
has several different meanings. The first object-oriented
language, Simula, had coroutines, an asynchronous
(quasi-parallel) form of message-passing in which the sender
saves its state and must be explicitly reawakened by a
resume call rather than by an automatic reply from the
receiver. Smalltalk and Loops equate message-passing with
remote procedure calls, a synchronous form of
message-passing in which the sender must wait for a reply
form the receiver before continuing. Modules in distributed
systems may communicate by rendezvous, which combines remote
procedure call with synchronization between the calling and
called processes by asynchronous message-passing, or both."

Wegner continues, "Objects certainly need to communicate,
but any form of message-passing appears to be compatible
with object-oriented programming."

- Polymorphism: Polymorphism is a measure of the degree of
difference in how each item in a specified collection of
items must be treated at a given level of abstraction.
Polymorphism is increased when any unnecessary differences,
at any level of abstraction, within a collection of items
are eliminated. (See [Gabriel, 1989], [Harland, 1984],
[Milner, 1978] and [Milner, 1984].) Most often we hear
discussions of polymorphism in terms of "overloading of
operation names or designators," i.e., which particular
method (algorithm) will be used for a given operation, given
a specific operand (or operands). [Polymorphism is, of
course, a much broader concept.] Using the operation/operand
theme, we can provide examples of several different types of
polymorphism, i.e.:

- general polymorphism -- where the same method is
used regardless of the type (or form) of the
operands,
- ad hoc polymorphism -- where a different method is
selected based on the type (or form) of the
operands, and

- parameterized polymorphism -- where the user of the
polymorphic abstraction must supply some
information, in the form of parameters, to the
abstraction.

In truth, even such languages as Fortran are somewhat
polymorphic, e.g., the same addition operator ("+") is used
for both integers and reals, although the method for each is
different. However, it is the polymorphic extensions, and
the ability to have user-defined polymorphic relationships,
which are attractive in many object-oriented languages.
[Few, if any, object-oriented languages are as polymorphic
as the ML language ([Milner, 1984]).]

- Persistence: Persistence is a measure of the volatility of
the state of an object. In object-oriented circles,
persistence is most often discussed in the context of
distributed applications (e.g., [Low, 1988]), or, more
commonly, in the context of object stores or databases
(e.g., [Merrow and Laursen, 1987]). Although some people
feel that persistence should be integrated into the
programming language itself (e.g., [Atkinson et al, 1983]),
this is not a very strong contender for a necessary
characteristic of object-oriented programming languages.

- Concurrency: One very important requirement for any
object-oriented application is that it closely model the
"real world," and the real world is usually highly
concurrent (as opposed to strictly sequential). Smalltalk is
decidedly strictly sequential. There are, however, a number
of concurrent object-oriented programming languages, e.g.,
Vulcan ([Kahn et al, 1987]), ABCL/1 ([Yonezawa et al,
1986]), and POOL-T ([America, 1987]). Unfortunately, none of
these "concurrent object-oriented programming languages"
appears headed for the mainstream.

- Reflection: Reflection is a process whereby a system knows
about itself as a computational, or structural, entity, and
has the capability to act on this knowledge. (See, e.g.,
[Ferber, 1989].) Reflection has been suggested as one method
for dealing with concurrency in object-oriented systems.
Very few, if any, people would include reflection as a
minimum characteristic for an object-oriented programming
language.

- Object-composition: Depending on who you are talking to, an
object can be a class, a metaclass, an instance, or some
other item. The classic concept of an object is that it is a
complete entity, having (at least the possibility of) the
ability to maintain state, presenting a specified interface
to the outside world, and hiding its internal
implementation. Commonly used examples of objects include
bank accounts, temperature sensors, stacks, and voltage.

Functional object-oriented programming languages, e.g.,
FOOPS ([Goguen and Meseguer, 1987]), allow "functions" to be
objects. "Traits" ([Curry and Ayers, 1984]), "mixins"
([Smith et al, 1987] and [Stefik and Bobrow, 1985]), and
"partial types" ([Halbert and O'Brien, 1987]) allow for
the implementation of partial concepts as objects.

Peter Wegner ([Wegner, 1987b]) suggests the following "dimensions" of
object-oriented language design:

- objects

- classes (object types)

- inheritance

- data abstraction

- strong typing

- concurrency

- persistence

He claims that these characteristics "span the design space of
object-based languages." He also observes ([Wegner, 1987a])
"object-based languages must possess the first," i.e. objects, and
that certain combinations of the above attributes may be incompatible.

Even if a general agreement on object-oriented characteristics can be
reached, there are other problems with the evaluation of a programming
language for object-oriented software engineering. Very often, all the
characteristics are given equal weight -- although many, if not most,
people have their own intuitive ranking of the importance of each
characteristic. A variation on this problem is the "all or nothing"
syndrome, i.e., if a programming language is missing, or has a poor
implementation of, even one characteristic, the programming language
is not considered object-oriented.

Bigotry is often a major problem with programming language evaluation.
Software engineers are, after all, human beings, and are thus subject
to human frailties. I have read quite a number of evaluations and
comparisons of programming languages, and I would have a hard time
trying to identify even one which was totally free of bias.
Unfortunately, I have read too many which do little to hide their
strong (non-technical) prejudice against a particular language.
Sloppiness is another major problem with evaluations. Many times I
have gotten the distinct impression that the authors of the evaluation
have not used, or even looked at, the programming languages they are
evaluating. Sometimes they seem to have scanned a list of reserved
words, and, not finding words such as "object" or "class," they assume
the language does not support object-oriented programming.

Another problem is the confusion about the original goals for the
programming language itself. Specifically, very few programming
languages were created solely with the idea of implementing a pure
object-oriented programming language. For example, the Ada programming
language was implemented for large, real-time, embedded applications,
where reliability is critical. Some of the thinking behind Ada
conflicts with some of the traditional object-oriented implementation
philosophy.

EVALUATION METHODOLOGY

Sometimes the evaluation criteria for an object-oriented programming
language seems biased in one direction, e.g., "how many of
Smalltalk's features does this language possess?" As part of the
evaluation of any candidate language for object-oriented software
engineering, I propose that three main questions be asked, viz:

1. What features does the candidate programming language have
that most "object-oriented" programming languages seem to
lack?

2. What features does the candidate programming language have
in common with most "object-oriented" programming
languages?

3. What features do most "object-oriented" programming
languages have that the candidate programming language
seems to lack?

Using the Ada programming language as an example, let us provide some
sample answers to these questions. (Please note that we are not saying
that Ada is better than X, or that Ada is not as good as Y. We are
merely using the language as an example.):

- Under the category of features that Ada possesses, and that
most object-oriented programming languages seem to lack we
have, for example:

- the capability of creating user-defined metaclasses.
Assuming that one can fashion a class in Ada using a
package which exports a type, for example, a
metaclass can be created by making that package
generic.

- exceptions (see, e.g., [Dony, 1988]). Ada provides
both language-defined exceptions, and the capability
for user defined exceptions. (I should point out
that Ada's exception mechanism differs from that
found in some object-oriented programming languages,
e.g., Mesa ([Mitchell et al, 1979]).)

- concurrency. Ada provides concurrency via its
tasking mechanism. While it is true that there are a
growing number of concurrent object-oriented
programming languages, the most popular
object-oriented programming languages still lack
concurrency, or a mature, well-understood means for
handling concurrency.

- types (strong typing). Many people have complained
about Ada's strong typing. This makes the trend
towards more strongly typed object-oriented
programming languages that much more ironic.

- the ability to address low-level, machine-dependent
items. Ada provides access to low-level aspects of
the environment via such things as representation
clauses. Few of the most popular object-oriented
programming languages directly allow access to
low-level, machine-dependent items. For example,
while C++ does seem to provide some access to the
hardware, Smalltalk and Eiffel generally avoid the
issue.

- a high degree of portability. Many programmers
confuse "compilability" with "portability." Just
because there are many implementations of a compiler
for a given language, does not mean that they will
all compile the same code, or that the compiled code
will exhibit the same semantics. (In truth, the main
reason for the possibility of producing highly
portable Ada source code, has more to do with the
infrastructure of Ada technology (e.g., validation)
than with the language itself.)

- Under the category of features that Ada shares in common
with most object-oriented programming languages we have, for
example:

- encapsulation: Ada's package construct allows for
the encapsulation of operations, methods,
exceptions, constants, and other items which can be
associated with an object (e.g., a class, an
instance, or a metaclass).

- information hiding: Ada's private types provide
an excellent mechanism for hiding information.
- data abstraction: Ada's generics afford a
software engineer the capability to make both
subprograms and packages generic. Used well, they
make the implementation of data abstraction fairly
easy.

- some types of polymorphism: Ada's ability to
overload operators, and names, as well as Ada's
ability to parameterize generic packages provide
some level of software engineer controlled
polymorphism.

- Under the category of features that Ada lacks in comparison
with most object-oriented programming languages we have, for
example:

- Smalltalk-like inheritance mechanism: No claim can
be made that Ada, in isolation, closely mirrors
Smalltalk-like inheritance. There are ways of
simulating this mechanism within the language (e.g.,
[Perez, 1988]), and ways to implement a static
"layers of abstraction" approach to inheritance. (We
should also note that there is a distinct difference
between genericity (provided by Ada's generics)
and inheritance. See, e.g., [Meyer, 1986].)

- some forms of polymorphism: The Ada language is not
as polymorphic as Lisp and its object-oriented
derivatives (e.g., Flavors), and nowhere near as
polymorphic as ML ([Milner, 1984]). Being a very
strongly typed language, some forms of polymorphism
(e.g., arrays with components of different types)
are precluded by definition. (Yes, there are ways
around this using, for example, variant records or
access types and unchecked_conversion, but these are
not direct methods.)

- dynamic binding: Ada's emphasis on reliability
shifts part of the burden to the programming
language itself. In languages which feature dynamic
binding (e.g., Objective-C ([Cox, 1986])), the onus
is more on the software engineer, and less on the
language, in terms of reliability. Therefore,
dynamic binding is an attribute which directly
conflicts with the original intentions of the Ada
language.

- some types of parameters: Not all Ada objects are
first-class objects. For example, objects
implemented using types exported from (generic)
packages, and objects implemented using task types
can participate in a quite a number of expressions,
and can be passed as parameters. However objects
implemented using objects exported from packages,
and objects implemented using tasks (and not task
types) cannot behave as first class objects.
Further, Ada's current non-support (or extremely
limited support) for such items as "package types,"
"subprogram types," "procedure parameters," and
"exceptions as parameters," precludes some types of
desirable polymorphic behavior.

[Note: A number of extensions to the Ada language (e.g., DRAGOON ([Di
Maio et al, 1989]), Classic Ada ([Donaldson, 1989]), Ada++ ([Forestier
et al, 1989]), and InnovAda ([Simonian and Crone, 1988a])) do address
each of these points. However, they are not part of the current
language definition ([DoD, 1983]).]

Of course, there are other considerations in the choice of an
implementation language e.g., availability on the desired platforms,
interfacing to other applications, customer requirements, and staff
training.

If one is developing a small and/or non-critical application, then all
that may be required is object-oriented programming (coding). However,
for large and/or critical applications, it is likely that one, or
more, of the following may be necessary: object-oriented design (OOD),
object-oriented requirements analysis (OORA), and object-oriented
domain analysis (OODA). In addition, object-oriented thinking will
permeate post-development life-cycle activities, management practices,
development standards, organizational policies and procedures, and
software quality assurance, among others.

This is an important point. As we move away from the myopic view of
considering what goes on during coding, and move towards a more
comprehensive (e.g., total life-cycle) perspective on software
engineering, our evaluation criteria for an object-oriented
programming language changes. Potential flaws, which were virtually
unnoticed during programming-in-the-small, become glaring deficiencies
in software-engineering-in-the-large.

It is crucial that a given programming language closely mirror the
thought processes which were introduced during requirements analysis,
and carried over to design. For example, if we find it natural to talk
about metaclasses during analysis and design, it is more than a little
helpful if our implementation language allows us to implement
metaclasses directly. The same is true for concepts such as
concurrency and inheritance.

CONCLUSION

Deciding whether a given programming is "object-oriented" is not as
simple as some people would have it. However, if each organization, or
installation, is aware of the issues, and the scope of their
object-oriented software engineering efforts, then intelligent choices
can be made.

Of course, this article can provide some fodder for academic
evaluation, and net discussion as well.

This is probably the biggest article I have submitted to comp.object.
I'll try to cut back on the size of future articles. Thank you for
listening.

-- Ed Berard
Berard Software Engineering, Inc.
18620 Mateney Road
Germantown, Maryland 20874
Phone: (301) 353-9652
FAX: (301) 353-9272

BIBLIOGRAPHY

[Agha, 1986]. G. Agha, "An Overview of Actor Languages," SIGPLAN
Notices, Vol. 18, No. 6, June 1983, pp. 58 - 67.
[America, 1987]. P. America, "POOL-T: A Parallel Object-Oriented
Language," in Object-Oriented Concurrent Programming, A. Yonezawa and
M. Tokoro, Editors, MIT Press, Cambridge, Massachusetts, 1987, pp. 199
- 220.

[Atkinson et al, 1983]. M.P. Atkinson, P.J. Bailey, W.P. Cockshott,
K.J. Chisholm, and R. Morrison, "An Approach to Persistent
Programming," Computer Journal, Vol. 26, No. 4, 1983, pp. 360 - 365.

[Bach, 1988]. W.W. Bach, "Is Ada Really an Object-Oriented Programming
Language," Proceedings of Ada Expo 1988, Galaxy Productions,
Frederick, Maryland, 1988, 7 pages.

[Bailin, 1988]. S.C. Bailin, "An Object-Oriented Specification Method
for Ada," Proceedings of the Fifth Washington Ada Symposium, June 27 -
30, 1988, Association for Computing Machinery, New York, New York,
1988, pp. 139 - 150.

[Bergin and Greenfield, 1988]. J. Bergin and S. Greenfield, "What Does
Modula-2 Need to Fully Support Object-Oriented Programming?," SIGPLAN
Notices, Vol. 23, No. 3, March 1988, pp. 73 - 82.

[Bobrow, 1983]. D.G. Bobrow, The LOOPS Manual, Rank Xerox, Inc., Palo
Alto, California, 1983.

[Buzzard and Mudge, 1985]. G.D. Buzzard and T.N. Mudge, "Object-Based
Computing and the Ada Programming Language," IEEE Computer, Vol. 18,
No. 3, March 1985, pp. 12 - 19.

[Cook, 1986]. S. Cook, "Languages and Object-Oriented Programming,"
Software Engineering Journal, Vol. 1, No. 2, 1986, pp. 73 - 80.

[Cox, 1986]. B.J. Cox, Object Oriented Programming: An Evolutionary
Approach, Addison-Wesley, Reading, Massachusetts, 1986.

[Curry and Ayers, 1984]. G.A. Curry and R.M. Ayers, "Experience with
Traits in the Xerox Star Workstation," IEEE Transactions on Software
Engineering, Vol. SE-10, No. 5, September 1984, pp. 519 - 527.

[Dahl and Nygaard, 1966]. O.J. Dahl and K. Nygaard, "SIMULA -- an
ALGOL-Based Simulation Language," Communications of the ACM, Vol. 9,
No. 9, September 1966, pp. 671 - 678.

[Di Maio et al, 1989]. A. Di Maio, C. Cardigno, R. Bayan, C.
Destombes, and C. Atkinson, "DRAGOON: An Ada-Based Object-Oriented
Language," Ada: the Design Choice -- Proceedings of the Ada-Europe
Conference, Madrid 13-15 June 1989, Cambridge University Press,
Cambridge, United Kingdom, 1989, pp. 39 - 48.

[DoD, 1983]. Reference Manual for the Ada Programming Language,
(ANSI/MIL-STD-1815A-1983), Government Printing Office, Washington,
D.C., 1983.

[Donaldson, 1989]. C.M. Donaldson, "Dynamic Binding and Inheritance in
an Object-Oriented Ada Design," Ada: the Design Choice -- Proceedings
of the Ada-Europe Conference, Madrid 13-15 June 1989, Cambridge
University Press, Cambridge, United Kingdom, 1989, pp. 16 - 25.

[Dony, 1988]. C. Dony, "An Object-Oriented Exception Handling System
for an Object-Oriented Language," ECOOP '88: Proceedings of the
European Conference on Object-Oriented Programming, Lecture Note on
Computer Science, Volume 322, Springer Verlag, New York, New York,
1988, pp. 146 - 161.

[Edelson, 1987]. D.R. Edelson, "How Objective Mechanisms Facilitate
the Development of Large Software Systems in Three Programming
Languages," SIGPLAN Notices, Vol. 22, No. 9, September 1987, pp. 54 -
63.

[Ferber, 1989]. J. Ferber, "Computational Reflection In Class Based
Object-Oriented Languages," OOPSLA '89 Conference Proceedings,
Special Issue of SIGPLAN Notices, Vol. 24, No. 10, October 1989, pp.
317 - 326.

[Forestier et al, 1989]. J.P. Forestier, C. Fornarino, and P.
Franchi-Zannettacci, "Ada++: A Class and Inheritance Extension for
Ada," Ada: the Design Choice -- Proceedings of the Ada-Europe
Conference, Madrid 13-15 June 1989, Cambridge University Press,
Cambridge, United Kingdom, 1989, pp. 3 - 15.

[Gabriel, 1989]. R.P. Gabriel, "Using the Common LISP Object System,"
Computer Language, Vol. 6, No.8, August 1989, pp. 73 - 80.

[Goguen and Meseguer, 1987]. J.A. Goguen and J. Meseguer, "Unifying
Functional, Object-Oriented and Relational Programming With Logical
Semantics," in Research Directions in Object-Oriented Programming, B.
Shriver and P. Wegner, Editors, The MIT Press, Cambridge,
Massachusetts, 1987, pp. 417 - 477.

[Goldberg and Robson, 1983]. A. Goldberg and D. Robson, Smalltalk-80:
The Language and Its Implementation, Addison-Wesley, Reading,
Massachusetts, 1983.

[Halbert and O'Brien, 1987]. D.C. Halbert and P.D. O'Brien, "Using
Types and Inheritance in Object-Oriented Programming," IEEE Software,
Vol. 4, No. 5, September 1987, pp. 71 - 79.

[Harland, 1984]. D.M. Harland, Polymorphic Programming Languages --
Design and Implementation, Halstead Press, New York, New York, 1984.

[Jacky and Kalet, 1987]. J.P. Jacky and I.J. Kalet, "An
Object-Oriented Programming Mechanism for Standard Pascal,"
Communications of the ACM, Vol. 30, No. 9, September 1987, pp. 772 -
776.
[Johnson, 1986]. R.E. Johnson, "Type-Checking Smalltalk," OOPSLA '86
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21,
No. 11, November 1986, pp. 315-321.

[Kahn et al, 1987]. K. Kahn, E. Tribble, M. Miller, and D. Bobrow,
"Vulcan: Logical Concurrent Objects," in Research Directions in
Object-Oriented Programming, B. Shriver and P. Wegner, Editors, The
MIT Press, Cambridge, Massachusetts, 1987, pp. 75 - 112.

[Keene, 1989]. S.E.Keene, Object-Oriented Programming in Common Lisp,
Addison-Wesley, Reading, Massachusetts, 1989.

[Kristensen et al, 1987]. B.B. Kristensen, O.L. Madsen, B.
Moller-Pedersen and K. Nygaard, "The BETA Programming Language," in
Research Directions in Object-Oriented Programming, B. Shriver and P.
Wegner, Editors, The MIT Press, Cambridge, Massachusetts, 1987, pp. 7
- 48.

[Lieberman et al, 1988]. H. Lieberman, L. A. Stein, and D. Unger, "Of
Types and Prototypes: The Treaty of Orlando," OOPSLA '87 Addendum
to the Proceedings, Special Issue of SIGPLAN Notices, Vol. 23, No. 5,
May 1988, pp. 43 - 44.

[Liskov et al, 1977]. B.H. Liskov, A. Snyder, R. Atkinson, and C.
Schaffert, "Abstraction Mechanisms in CLU," Communications of the ACM,
Vol. 20, No. 8, August 1977, pp. 564 - 576.

[Liskov, 1988]. B. Liskov, "Data Abstraction and Hierarchy," OOPSLA
'87 Addendum to the Proceedings, Special Issue of SIGPLAN Notices,
Vol. 23, No. 5, May 1988, pp. 17 - 34.

[Low, 1988]. C. Low, "A Shared Persistent Object Store," ECOOP '88:
Proceedings of the European Conference on Object-Oriented Programming,
Lecture Note on Computer Science, Volume 322, Springer Verlag, New
York, New York, 1988, pp. 390 - 410.

[Merrow and Laursen, 1987]. T. Merrow and J. Laursen, "A Pragmatic
System for Shared Persistent Objects," OOPSLA '87 Conference
Proceedings, Special Issue of SIGPLAN Notices, Vol. 22, No. 12,
December 1987, pp. 103 - 110.

[Meyer, 1986]. B. Meyer, "Genericity Versus Inheritance," OOPSLA
Conference Proceedings, (Special Issue of SIGPLAN Notices, Vol. 21,
No. 11, November 1986), Association for Computing Machinery, New York,
New York, 1986, pp. 391 - 405.

[Meyer, 1987]. B. Meyer, "Eiffel: Programming for Reusability and
Extendability," SIGPLAN Notices, Vol. 22, No. 2, February 1987, pp. 85
- 94.

[Milner, 1978]. R. Milner, "A Theory of Type Polymorphism in
Programming," Journal of Computer and System Sciences, Vol. 17, 1978,
pp. 348 - 375.

[Milner, 1984]. R. Milner, "A Proposal for Standard ML," ACM Symposium
on Lisp and Functional Programming, August 1984, pp. 184 - 197.

[Mitchell et al, 1979]. J. Mitchell, W. Maybury, and R. Sweet, Mesa
Language Manual, Technical Report, Xerox PARC, Palo Alto, California,
1979.

[Moon, 1986]. D.A. Moon, "Object-Oriented Programming With Flavors,"
OOPSLA Conference Proceedings, (Special Issue of SIGPLAN Notices, Vol.
21, No. 11, November 1986), Association for Computing Machinery, New
York, New York, 1986, pp. 1 - 8.

[Perez, 1988]. E.P. Perez, "Simulating Inheritance With Ada," Ada
Letters, Vol. 8, No. 5, September-October, 1988, pp. 37 - 46.

[Schaffert et al, 1986]. C. Schaffert, T. Cooper, B. Bullis, M.
Killian, and C. Wilpolt, "An Introduction to Trellis/Owl," OOPSLA '86
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21,
No. 11, November 1986, pp. 9 - 16.

[Simonian and Crone, 1988a]. R. Simonian and M. Crone, "INNOVADA: An
Object-Oriented Ada Environment," Proceedings of the U.S. Army
Information Systems Engineering Command Advanced Technology Office --
Technology Strategies '88 Conference, February 9-12, 1988, The
American Defense Preparedness Association, Washington, D.C., pp. 63 -
74.

[Simonian and Crone, 1988b]. R. Simonian and M. Crone, "InnovAda: True
Object-Oriented Programming In Ada," Journal of Object-Oriented
Programming, Vol. 1, No. 4, November/December 1988, pp. 14 - 21.

[Smith et al, 1987]. R.G. Smith, P.S. Barth, and R.L. Young, "A
Substrate for Object-Oriented Interface Design," in Research
Directions in Object-Oriented Programming, B. Shriver and P. Wegner,
Editors, The MIT Press, Cambridge, Massachusetts, 1987, pp. 253 - 315.

[Snyder, 1986]. A. Snyder, "Encapsulation and Inheritance in
Object-Oriented Programming Languages," OOPSLA '86 Conference
Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No. 11,
November 1986, pp. 38 - 45.

[Stefik and Bobrow, 1985]. M. Stefik and D.G. Bobrow,
"Object-Oriented Programming: Themes and Variations," The AI Magazine,
1985, pp. 40 - 62.

[Stein, 1987]. L.A. Stein, "Delegation Is Inheritance," OOPSLA '87
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 22, No.
12, December 1987, pp. 138 - 146.

[Stroustrup, 1986]. B. Stroustrup, "An Overview of C++," SIGPLAN
Notices, Vol. 21, No. 10, October 1986, pp. 7 - 18.

[Touati, 1987]. H. Touati, "Is Ada an Object-Oriented Programming
Language?," SIGPLAN Notices, Vol. 22, No. 5, May 1987, pp. 23 - 26.

[Unger and Smith, 1987]. D. Ungar and R.B. Smith, "Self: The Power of
Simplicity," OOPSLA '87 Conference Proceedings, Special Issue of
SIGPLAN Notices, Vol. 22, No. 12, December 1987, pp. 227 - 242.

[Waurzyniak, 1989]. P. Waurzyniak, "Borland Pulls Object Orientation
Into Its Fold," ComputerWorld, Vol. 23, No. 18, May 1, 1989, page 37.

[Wegner, 1983]. P. Wegner, "On the Unification of Data and Program
Abstraction in Ada," Proceedings of the 10th Annual ACM Symposium on
Principles of Programming Languages, 1983, pp. 256 - 264.

[Wegner, 1986]. P. Wegner, "Classification in Object-Oriented
Systems," SIGPLAN Notices, Vol. 21, No. 10, October 1986, pp. 173 -
182.

[Wegner, 1987a]. P. Wegner, "The Object-Oriented Classification
Paradigm," in Research Directions in Object-Oriented Programming, B.
Shriver and P. Wegner, Editors, The MIT Press, Cambridge,
Massachusetts, 1987, pp. 479 - 560.

[Wegner, 1987b]. P. Wegner, "Dimensions of Object-Based Language
Design," OOPSLA '87 Conference Proceedings, Special Issue of
SIGPLAN Notices, Vol. 22, No. 12, December 1987, pp. 168 - 182.

[Wegner, 1989]. P. Wegner, "Learning the Language," Byte, Vol. 14, No.
3, March 1989, pp. 245 - 253.

[Wirth, 1983]. N. Wirth, Programming In Modula-2, Second Edition,
Springer-Verlag, New York, New York, 1983.

[Wolf, 1989]. W. Wolf, "A Practical Comparison of Two Object-Oriented
Languages," IEEE Software, Vol. 6, No. 5, September 1989, pp. 61 - 68.

[Yonezawa et al, 1986]. A. Yonezawa, J.-P. Briot, and E. Shibayama,
"Object-Oriented Concurrent Programming in ABCL/1," OOPSLA '86
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No.
11, November 1986, pp. 258 - 268.
[Zaniolo, 1984]. C. Zaniolo, "Object-Oriented Programming in Prolog,"
1984 International Symposium on Logic Programming, Atlantic City, New
Jersey, February 1984, IEEE Computer Society Press, Washington, D.C.,
pp. 265 - 270.