Instructor's Guide
intro,
paradigms,
comparison,
design,
prototypes,
architectures,
summary,
Q/A,
literature
How would you characterize Ada83? See [Barnes94].
Is Ada object-oriented?
And Modula-2?
See [Wirth83].
The answer is no and no.
And Ada9X and Modula-3?
See [Barnes94] and [Card89].
The answer is yes and yes.
In the past there has been some confusion
as to when to characterize a language as
object-oriented.
For example, [Booch86] characterizes Ada as
object-oriented and motivates this by saying that Ada
can be used as an implementation language in
an object-oriented approach to program development.
Clearly, Ada supports some notion of objects (which
are defined as packages).
However, although Ada supports objects and generic descriptions
of objects (by generic packages), it does not support
code sharing by inheritance.
In a later work, [Booch91] revises his original (faulty)
opinion, in response to
[Wegner87], who proposed considering inheritance
as an essential characteristic of object orientation.
Similarly, despite the support that Modula-2 offers
for defining (object-like) abstract data types,
consisting of
an interface specification and an implementation
(which may be hidden), Modula-2 does not support
the creation of derived (sub)types that share
the behavior of their base (super)type.
See also section [adt-modules].
Classes versus types
Another confusion that frequently arises
is due to the ill-defined relationship between
the notion of a class and the notion of a type.
The notion of types is already familiar
from procedural programming languages such as
Pascal and (in an ill-famed way) from C.
The type of variables and functions may be profitably
used to check for (syntactical) errors.
Strong static type checking may prevent errors
ranging from simple typos to using undefined
(or wrongly defined) functions.
The notion of a class originally has a more
operational meaning.
Operationally, a class is a template for object creation.
In other words, a class is a description of the collection
of its instances, that is the objects that are
created using the class description as a recipe.
Related to this notion of a class, inheritance was
originally defined as a means to share (parts of)
a description.
Sharing by (inheritance) derivation is, pragmatically,
very convenient.
It provides a more controlled way of code sharing
than, for example, the use of macros and file inclusion
(as were popular in the C community).
Since [Wegner87] published his original analysis
of the dimensions of object-oriented language design,
the phrase object-oriented has been commonly understood
as involving objects, classes and inheritance.
This is the traditional object model as embodied
by Smalltalk and, to a large extent, by Eiffel, C++ and Java.
However, unlike Smalltalk, both Eiffel and C++ have also been
strongly influenced by the abstract data type approach
to programming.
Consequently, in Eiffel and C++ classes have been identified
with types and derivation by inheritance with subtyping.
Unfortunately, derivation by inheritance need not necessarily
result
in the creation of proper subtypes,
that is classes whose instances conform to the behavior
specified by their base class.
In effect, derived classes may be only distantly related
to their base classes when inheritance is only
used as a code sharing device.
For example, a window manager class may inherit
from a list container class (an idiom used in Meyer, 1988).