eberard@ajpo.sei.cmu.edu (Edward Berard) (01/03/90)
"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.jimad@microsoft.UUCP (JAMES ADCOCK) (01/04/90)
While the previous suggestions regarding evaluating OO Languages I found generally good, here is a list of things I think us grunts down in the trenches would pragmatically like to know about a language before spending too much time on it: -> Message dispatch times in a variety of schenerios [static vs dynamic binding, single vs multiple inheritence, etc] relative to function call times in a specific traditional language such as C or Pascal. Timing comparisons should specify what compilers on what machines are being compared, using what compile and link options [if any.] Do not specify what performance *may* be achieved with a better compiler. Rather, specify what performance *is* being acheived with *today's* compiler. Use the most-speed-optimized compiler options. -> Dynamic object creation time for a typical small object. Give absolute time in microseconds for a specific machine, and compare to malloc times on that system. -> Specify "hello world" minimum stand-alone run-time executable size, where that size would be the total number of bytes that must be transported to a system that never saw anything in this language before. Compare to a minimal C or Pascal "hello world" executable on that system for comparison. -> Include at least some simple common timing and size comparisons that people have experience with -- such as an "Object-Oriented" version of Ackerman's function. Compare to timings in a traditional language such as C or Pascal. Use most-speed-optimized compiler options -- specify what compilers and options are used. Don't use just the "traditional language" subset of your language -- we can already guess that Ackerman's function implemented in a C subset of C++ is going to run as fast as a K&R C version, and we can guess that most OO Languages include provisions for importing an assembly language version of Ackerman's. Rather, implement a simple, straight-forward version, using many of the features of the language you are advertising as being "good." -> Include a list of traditional language features such as found in C or Pascal that are *not* in this language [not to imply such a lack is *bad* or *good*] -> Specify what compilers are generally available for what machines at what costs and restrictions. *Try* to be accurate. Are there different costs for commercial vs educational users? Are there restrictions on what one can do with executables built from this system? Restrictions on linking libraries? etc. -> Specify what books or documentation [if any] are generally available for this language. -> What does it take to use modules written in other languages with this language? What does it take to use modules written in this language with other languages? Yes, there was a time when C couldn't easily call Pascal couldn't easily call Fortran. Now many Object Oriented Languages have at least some ability *to call* routines/modules from other languages. Sadly, few Object Oriented Languages offer much ability to allow their routines/modules *to be called* from other languages.
jacob@gore.com (Jacob Gore) (01/04/90)
/ comp.object / eberard@ajpo.sei.cmu.edu (Edward Berard) / Jan 2, 1990 / > As part of the > evaluation of any candidate language for object-oriented software > engineering, I propose that three main questions be asked [...] I would add a subquestion to each of these: Are the features under consideration easy and natural to use in the languages being compared, or does the programmer have to go through a lot of effort to make use of them? In the case of Ada, one example of "a lot of effort" is when programmers use task types to implement classes of objects that have nothing to do with concurrency, because package types, the natural thing to use for the problem at hand, are lacking in the language. > - Under the category of features that Ada lacks in comparison > with most object-oriented programming languages we have, for > example: [...] > - 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. Are these goals truly conflicting? I don't think so. Dynamic binding need not be unconstrained, and it need not be done at the expense of static typing. Some of the common O-O languages (e.g., C++, Eiffel, and even the current version of Objective-C) take advantage of the concept of subtyping for this: generally speaking, an operation taking an object of type T as a parameter will also accept an object of any type T' which is a subtype of T. The assumption is that whatever can be safely done to an instance of T can also be safely done to an instance of T'. Is this assumption inconsistent with Ada's ways of emphasizing reliability? (This, of course, cannot be done in Ada-83 since it does not provide a syntactic (for the benefit of the compiler, as well as the programmer) way to create subtypes of user-defined types. ...Well, maybe it can be done, but not in a straight-forward manner.) > ... Not all Ada objects are first-class objects. That, in my view, is the biggest problem. Not just with Ada, and not just concerning object-oriented programming. I hate it when there are things in a language that can be done with predefined types but not with programmer-defined types. For example (I'm not talking about Ada specifically), when only predefined types can be initialized and finalized. Or when you can have arrays of INTEGERs, but not of SQUIRRELs. Or when the "+" in "A+B" can be overloaded for predefined types, but not for programer-defined types. Or when there is a group of "standard" functions that take a variable number of parameters, but the programmer has no way to define such a function. An object-oriented language, first and foremost, should make it easy and natural to define and use objects. This means that all objects -- programmer-defined and language-defined -- should be first class entities in the language. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
sakkinen@tukki.jyu.fi (Markku Sakkinen) (01/04/90)
In article <10132@microsoft.UUCP> jimad@microsoft.UUCP (JAMES ADCOCK) writes: >While the previous suggestions regarding evaluating OO Languages I found >generally good, here is a list of things I think us grunts down in the >trenches would pragmatically like to know about a language before spending >too much time on it: > >-> Message dispatch times [...] > >-> Dynamic object creation time for a typical small object. [...] Good. >-> Specify "hello world" minimum stand-alone run-time executable size, > where that size would be the total number of bytes that must be transported > to a system that never saw anything in this language before. Compare > to a minimal C or Pascal "hello world" executable on that system > for comparison. Since a "hello world" program has no importance, neither has its size. OOP is mostly there to help the building of large and complicated programs. A fully-fledged OO language typically needs a rather large run-time system, independently of the size of the "main program". I think that the condition, "a system that never saw anything in this language before", is especially pointless. >-> Include at least some simple common timing and size comparisons that > people have experience with -- such as an "Object-Oriented" version > of Ackerman's function. [..] This looks to me as another highly irrelevant criterion. Ackerman's function is simply not the kind of thing that abounds in ordinary applications. I suspect it would be unfavourable to most OO languages, too. Because the above four were the only performance-related aspects mentioned, I wanted to criticise the choice. The rest of questions in the original posting were good and to the point, I think. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland
snorri@rhi.hi.is (Snorri Agnarsson) (01/04/90)
From article <638@ajpo.sei.cmu.edu>, by eberard@ajpo.sei.cmu.edu (Edward Berard): > ... > - 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. I agree that binding is an important issue in evaluating OO programming languages; in fact I suggest that a programming language should not be considered object oriented unless it has dynamic binding of methods to messages, the binding being on a per-object basis. All the programming languages I would consider object orientet have this feature, including for example Smalltalk, Eiffel, Turbo Pascal 5.5 and C++. Offhand, I think dynamic binding is more important than inheritance. Inheritance is more easily simulated by "buying". If Ada had dynamic binding I would agree to call it an object oriented programming language, but if it had inheritance and no dynamic binging, I be very reluctant to do so. > > 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. Some object oriented programming languages have both dynamic binding and object orientation, for example C++, Turbo Pascal 5.5 and Eiffel. I have not used Eiffel, but what I have seen about it suggests it has a much better typing scheme than other object oriented programming languages I know of. > ...[more features defining oo-languages] I would like to add a feature to the list which I believe has great effect on the way it can be used: - Automatic memory deallocation: Smalltalk and Eiffel are examples of OO-programming languages having this feature. It is much easier to do encapsulation in a language having this feature since we do not have to spend as much effort on describing memory management issues in the use of the encapsulated thing (in most cases we can entirely ignore the issue). Taking the memory management burden from the shoulders of the programmer and placing it on the run-time system is a prerequisite for elegant programming-in-the-large, in my opinion. C++ has a more restricted form of automatic deallocation, where the object is deallocated as it goes out of scope. This is more work for the programmer, who has to supply destructor methods for deallocation. Also, this can lead to more memory use, since sharing memory in different structures is hindered. > > 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 Please don't cut back on my account, at least. And thanks for all the thought-provoking articles. -- Snorri Agnarsson -- Snorri Agnarsson | Internet: snorri@rhi.hi.is Taeknigardur, Dunhaga 5 | UUCP: ..!mcvax!hafro!rhi!snorri IS-107 Reykjavik, ICELAND
anders@cui.unige.ch (BJORNERSTEDT Anders) (01/05/90)
In article <638@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: > 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 Was Smalltalk really available in the "very early 1970s" ? Speaking from personal experience from the early 80s, I was working with Simula. OO-terminology was certainly used at that time, but as I remember it Smalltalk was not readily available. >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." There is also a confusion between terminology and concepts. The Smalltalk notion of "message passing" (synchronous and blocking) is closer to the normal function call (especially if you have virtual functions like in Simula) than it is to "message passing" in the sense of the actor model of Hewitt. > - 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 I would argue that types are an old concept in object-oriented programming... > - Static Versus Dynamic Binding: Binding is the association of > allowable operands (i.e., objects) with operations. Binding This sounds like the binding of actual to formal parameters. What you mean is: Static versus dynamic binding of method. which is the binding of method to a given invocation including operands. > 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. You are correct here because you qualify with the first sentence with "usually". Strong typing and "dynamic binding of method" are theoretically orthogonal. > - 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. True, but the "normal" way of doing oo-programming in Simula is by invoking functions/procedures on instances of classes, which corresponds closely if not exactly to how it is done in Smalltalk. But I agree that the term "message passing" has degenerated as much as the term OO itself. > 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. I would just say "procedure call" and not "remote procedure call" when speaking of Smalltalk and Loops which in their standard form do not support distribution. Lets not add the term RPC to the list of terms which have lost meaning. > - 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. Uh-Oh, you (Edward Berard) seem to be biased against strong typing. Whether or not strong typing is desirable depends on 1) personal taste and 2) the problem to be solved and its context. I would argue that strong typing (which does not exclude polymorphism) is more important in large and critical applications.
jimad@microsoft.UUCP (JAMES ADCOCK) (01/06/90)
In article <2626@tukki.jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) SAKKINEN@FINJYU.bitnet (alternative) writes: > >>-> Specify "hello world" minimum stand-alone run-time executable size, >> where that size would be the total number of bytes that must be transported >> to a system that never saw anything in this language before. Compare >> to a minimal C or Pascal "hello world" executable on that system >> for comparison. > >Since a "hello world" program has no importance, neither has its size. >OOP is mostly there to help the building of large and complicated programs. >A fully-fledged OO language typically needs a rather large run-time >system, independently of the size of the "main program". >I think that the condition, "a system that never saw anything >in this language before", is especially pointless. I use the "hello world" example as one which almost everyone has experience with -- and almost everyone has some interest in knowing the minimum executable size associated with a language. I don't use C++ just for large projects. I use C++ for virtually every everyday programming task. Knowing how small an executable a language can produce can tell you how small a programming task a language can handle. It can also tell you how small a machine the language can use -- if the minimum executable a language can produce is four megs, its not going to run on many home machines or low end PCs. Its probably not going to be used for many commercial application developments either -- because the language is going to require a whole bunch more floppies or tapes to be shipped so the purchaser can load the product. Also, in my experience, software developers create all kinds of little or medium size tools for internal consumption -- loading many of these on a machine is prohibitive if they take a couple megs a shot. And if I choose to program in Gwhizl, its unreasonable to expect all my cohorts to also install a 4-meg $900 copy of Gwhizl on their machine just so they can run my 2-person/days tool. Even among languages that do require substantial runtime support, it is still useful to be able to compare a language that requires 2 megs of runtime support to one that requires 4 megs of runtime support. Also, being informed of large runtime support requirements warns one to be suspicious that probably everyone running programs developed in this language is going to be forced by license agreement to buy a copy of the language -- or that there is going to be some other major licensing restrictions. Not always -- but forewarned is fore-armed. >>-> Include at least some simple common timing and size comparisons that >> people have experience with -- such as an "Object-Oriented" version >> of Ackerman's function. [..] > >This looks to me as another highly irrelevant criterion. >Ackerman's function is simply not the kind of thing that abounds >in ordinary applications. I suspect it would be unfavourable to >most OO languages, too. My intent here is to demand that OOPLs have *some* responsibility for reporting performance numbers. Ackerman's function is the simplest, grungiest, most commonly found example which one sees *everywhere* Publish your favorite language's performance on Ackerman's or some other better common spec, and *then* defend why your language is *good* is spite of this performance. Is Gwhizl a factor of 2X slower than C or Pascal on this simple stuff? -- Hey doesn't sound bad to me -- this language is worth looking into! Is Gwhizl a factor of 10X slower than C or Pascal? Sounds like a pain to me. Come back when you have a good optimizing compiler! Is Gwhizl a factor of 100X slower than C or Pascal? Don't call me, I'll call you! My claim is that most of programming in any language is made of pretty simple straightforward stuff -- assignments, flow of control, method dispatches, etc -- hence the whole RISC revolution to do simple stuff well. Thus I claim it *is* fair to ask OOPLs to show some performance numbers indicative of how they do on this kind of simple stuff. And even if it *isn't* fair, it still doesn't mean that OOPLs should avoid publishing these numbers. Because a large number of potential users are *still* going to insist on these numbers before they plunk down their hard earned $$$ [Or worse, before they go try to convince their bosses to switch from C to Gwhizl]
jimad@microsoft.UUCP (JAMES ADCOCK) (01/06/90)
Also, add to my list of pragmatic wanna-knows: -> Specify representative compilations speeds in lines per second. Include link times in this computation if your language has a separate link phase. And if your language supports incremental compilation, publish separate indicative performance results for the incremental compiling mode, and for traditional "recompile-the-world" global builds.
eberard@ajpo.sei.cmu.edu (Edward Berard) (01/07/90)
In article <706@cui.unige.ch>, anders@cui.unige.ch (BJORNERSTEDT Anders) writes: > In article <638@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: > > > 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 > > Was Smalltalk really available in the "very early 1970s" ? > Speaking from personal experience from the early 80s, I was working with > Simula. OO-terminology was certainly used at that time, but as I remember > it Smalltalk was not readily available. The first version of Smalltalk was Smalltalk-72 (e.g., [Goldberg and Kay, 1976]), which was "available" in 1972. There were also versions released in 1974 and 1976 (e.g., [Ingalls, 1978]). The most important, and most widely distributed version became available in 1980, i.e., Smalltalk-80. The August 1981 issue of Byte was a special issue on Smalltalk, and contained at least 5 articles on Smalltalk and object-oriented programming. To be sure, the introduction of Simula, preceded the first introduction of Smalltalk by at least 6 years. (See, e.g., [Dahl and Nygaard, 1966].) Further, Alan Kay acknowledged his debt to Simula both in the attempted creation of FLEX, and in the development of Smalltalk. (See [Kay, 1977].) However, Smalltalk is significantly different from Simula. Specifically, it contains features which are "lacking" in Simula, and many consider these "missing" features essential to an object-oriented language. [Note: It is interesting to watch some people discuss the origins of object-oriented programming languages. On one hand, they wish to cite the introduction of Simula as the beginning of object-oriented programming. This provides the "credibility" of being around for about 24 years. On the other hand, some of these same people will say that "Smalltalk was the first 'true' object-oriented programming language." However, this gives them only about 18 years of longevity, i.e., going from Smalltalk-72.] REFERENCES [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. [Goldberg and Kay, 1976]. A. Goldberg and A. Kay, Editors, Smalltalk-72 Instructional Manual, Technical Report SSL-76-6, Xerox PARC, Palo Alto, California, March 1976. [Ingalls, 1978]. D.H.H. Ingalls, "The Smalltalk-76 Programming System Design and Implementation," Fifth Annual ACM Symposium on the Principles of Programming Languages, January 1978, pp. 9 - 15. [Kay, 1972]. A. Kay, "A Personal Computer For Children of All Ages," Proceedings of the ACM National Computer Conference, Boston, Massachusetts, August 1972. [Kay, 1977]. A.C. Kay, "Microelectronics and the Personal Computer," Scientific American, Vol. 237, No. 3, September 1977, pp. 230 - 244. [Krasner, 1983]. G. Krasner, Smalltalk-80: Bits of History, Words of Advice, Addison-Wesley, Reading, Massachusetts, 1983. [Schoch, 1979]. J. Schoch, "An Overview of the Language Smalltalk-72," SIGPLAN Notices, Vol. 14, No. 9, September 1979, pp. 64 - 73. > > >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." > > There is also a confusion between terminology and concepts. The > Smalltalk notion of "message passing" (synchronous and blocking) is > closer to the normal function call (especially if you have virtual > functions like in Simula) than it is to "message passing" in the sense > of the actor model of Hewitt. I will grant anyone that "message passing" has a multitude of meanings. What is important is that the objects which populate a system have some means of communicating with each other (and the outside world). To engage in a discussion of what constitutes "true message passing," or the "best message passing" is to accept an invitation into a black hole. > > > - 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 > > I would argue that types are an old concept in object-oriented programming... Here you have me, sir. By not being more precise than I was, I have left myself wide open. I could argue your point by citing a classic definition of types, i.e.: "A type defines a set of values, and a set of operations applicable to those values." In this sense, all programming languages, even "older" object-oriented programming languages, have types. However, this is not the point. In Smalltalk, the concept of "class" extends to the lowest levels, and the term "type" cannot even be found in the index of [Goldberg and Robson, 1983]. When object-oriented thinking began moving to languages other than Smalltalk, there was a collision between "classes" and "types." Questions began to arise, e.g.: - Are classes and types the same thing? - Are classes a form of types, or are types a form of classes? - If classes and types are different, _how_ are they different? Some of this discussion has led to some interesting results. (In another message, I will reproduce some discussions on typing in Smalltalk.) In fact, the definition of types that I furnished in the original article is but one of many interpretations of types in an object-oriented programming language. Depending on which definition you favor at the moment, I am either accurate, or "way off base." > > > - Static Versus Dynamic Binding: Binding is the association of > > allowable operands (i.e., objects) with operations. Binding > > This sounds like the binding of actual to formal parameters. What you > mean is: Static versus dynamic binding of method. which is the binding > of method to a given invocation including operands. This leads to some interesting discussions. For example, if you are in a situation where you have "ad hoc polymorphism," i.e., the method selected for a particular operation will depend on the class/type of the operand(s), then you can view the situation as you have described it. If, however, you have "general polymorphism," i.e., the same method will be used for the operation regardless of the class/type of the operand(s), then some other explanation may be necessary. [There is also the concept of "inside views" vs. "outside views." Specifically, do you describe binding from the viewpoint of those outside the object, i.e., where they cannot tell if different methods are being selected, or do you describe binding from the viewpoint of inside the object, i.e., where you can tell exactly how a given operation is being accomplished?] > > > 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. > > You are correct here because you qualify with the first sentence with > "usually". Strong typing and "dynamic binding of method" are theoretically > orthogonal. You will find many people who will disagree with you on this point. For example, I also received another opinion on this same section of my original article: "It seems to imply that strongly-typed languages are never associated with dynamic binding: but C++, Trellis, Eiffel, and Modula-3 are clearly strongly-typed and support dynamic binding. (One place where binding may have been discussed is in the functional programming community, where a function variable is "dynamically bound" in contrast to a static function reference. Even C supports dynamic binding through function pointers.)" > > True, but the "normal" way of doing oo-programming in Simula is by invoking > functions/procedures on instances of classes, which corresponds closely > if not exactly to how it is done in Smalltalk. But I agree that the term > "message passing" has degenerated as much as the term OO itself. See my earlier comment about discussing message passing. > > > 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. > > I would just say "procedure call" and not "remote procedure call" > when speaking of Smalltalk and Loops which in their standard form > do not support distribution. Lets not add the term RPC to the list of > terms which have lost meaning. All I intended to say (by quoting Peter Wegner) was that message passing has a number of different interpretations and implementations. > > > - 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. > > Uh-Oh, you (Edward Berard) seem to be biased against strong typing. > Whether or not strong typing is desirable depends on 1) personal taste > and 2) the problem to be solved and its context. I would argue that > strong typing (which does not exclude polymorphism) is more important > in large and critical applications. [Note: If you could see my mail (;-)). If I did not know any better, I would think it was a plot. Some of you guys must have gotten together beforehand and agreed to send contradicting messages (;-) ;-)). I got another message accusing me of being biased _in_ _favor_ _of_ strong typing. Ah, ... but such is life. 8^}] You get half credit (;-)). I am biased. (Horrors! :-)) However, I am biased in your direction. I tend to agree strongly with you that strong typing is more important in large and critical applications. -- Ed Berard (301) 353-9652
jimad@microsoft.UUCP (JAMES ADCOCK) (01/09/90)
Can you please choose some other discriptor rather than "ad hoc polymorphism" ??? This term is not descriptive, is being applied to a technique that is certainly *not* "ad hoc," and sounds like it is intended to be prejudicial terminology -- which I'm sure was not your intent!
dlw@odi.com (Dan Weinreb) (01/10/90)
In article <644@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
I know I'm just quibbling about an unimportant point here; I'm not
really taking issue with the main body of what you're saying.
The first version of Smalltalk was Smalltalk-72 (e.g., [Goldberg and
Kay, 1976]), which was "available" in 1972. There were also versions
released in 1974 and 1976 (e.g., [Ingalls, 1978]). The most important,
and most widely distributed version became available in 1980, i.e.,
Smalltalk-80. The August 1981 issue of Byte was a special issue on
Smalltalk, and contained at least 5 articles on Smalltalk and
object-oriented programming.
It depends on what you mean by "available" in double-quotes. It was
available if you happened to be an employee of Xerox PARC. But as of
1976, Xerox was not releasing any information about Smalltalk (any
version thereof). I vividly remember the situation at MIT at the
time, where many people had heard of Smalltalk and were trying to find
out more about it. The paper you cite, [Goldberg and Kay, 1976], was
not available for external distribution. At MIT, we were only able to
read it because someone managed to extract a copy from Xerox via a
clever deception; this copy was then passed around by hand at MIT. In
1977, some of our friends at Xerox slipped us out some information
about what was to become Smalltalk-78. I'm not sure when Xerox
finally let down the wall of secrecy, but I'm quite sure that it was
later than early 1977.
I know it may be hard to believe now, but at the time, Xerox had a
reputation for secrecy. Since then, of course, all that has changed,
and they distribute a wealth of fascinating high-quality research.anders@cui.unige.ch (BJORNERSTEDT Anders) (01/10/90)
In article <644@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: >In article <706@cui.unige.ch>, anders@cui.unige.ch (BJORNERSTEDT Anders) writes: >> In article <638@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: EB>Smalltalk. (See [Kay, 1977].) However, Smalltalk is significantly EB>different from Simula. Specifically, it contains features which are EB>"lacking" in Simula, and many consider these "missing" features EB>essential to an object-oriented language. The main difference between Smalltalk and Simula I see as being on the system level, not on the language semantics level. Smalltalk is interpreted by an abstract machine and uses dynamic linking, simula is strongly typed, statically linked (but still has dynamic binding through virtuals). Simula also contains features which are lacking in Smalltalk (strong typing, nested classes, and coroutine stuff which I dont regard as having much to do with object orientation, etc). Anyway I dont want to get into a useless debate on the differences and merits of Simula and Smalltalk. I was mainly concerned with the history of "oo-concepts", and strong typing. When you say that there are "missing" features in Simula which some regard as essential to an object-oriented language, I would be interested in hearing what those features are. Not because I want to enter the black hole of how we should define "OO", but because I suspect that many people are not familiar with Simula and possibly do not understand what features it has. EB>I will grant anyone that "message passing" has a multitude of EB>meanings. What is important is that the objects which populate a EB>system have some means of communicating with each other (and the EB>outside world). To engage in a discussion of what constitutes "true EB>message passing," or the "best message passing" is to accept an EB>invitation into a black hole. The point I was trying to make is that Smalltalk and Simula have essentially the same model of message passing, method invocation, procedure call, or whatever you want to call it. The Simula model is a bit more elaborate since you can have either dynamic or static binding whereas in Smalltalk you can only have dynamic binding. Smalltalk is more flexible because of the lack of strong typing, not because of any fundamentally different message passing model. EB>> > those operations. Types are a relatively new concept in EB>> > object-oriented programming. Smalltalk has, in effect, no AB>> AB>> I would argue that types are an old concept in object-oriented programming... EB> EB>Here you have me, sir. By not being more precise than I was, I have EB>left myself wide open. I could argue your point by citing a classic --------Deleted discussion on definition of typing------------------ I think you misunderstood me. I was not trying to be an obnoxious philosopher claiming that Smalltalk is typed in some sense. I agree that typing is a "new" topic with respect to Smalltalk. What I meant was simply that Simula is strongly typed (according to all reasonable definitions of strong typing (give me a break here)). and hence types are not a new concept in OOP. EB>> > Static binding is usually associated with strongly typed EB>> > programming languages, and dynamic binding with weakly-typed EB>> > programming languages. Smalltalk and Objective-C support EB>> > dynamic binding. AB>> AB>> You are correct here because you qualify with the first sentence with AB>> "usually". Strong typing and "dynamic binding of method" are theoretically AB>> orthogonal. EB> EB>You will find many people who will disagree with you on this point. 1- Strong typing/Static binding. pascal/normal operations in simula etc. 2- Strong typing/Dynamic binding. Virtuals in simula. 3- Untyped/ Static binding. C functions. C is typed but checking is weak 4- Untyped/ Dynamic binding. Smalltalk So the two are not only theoretically orthogonal, I have given you practical examples of all four possibilities. Now how can someone disagree with the theoretical independence between strong typing and dynamic binding of methods ? Case 3 may be a bit constructed, but this is because its usefullness is questionable, not because it is theoretically impossible. EB>For example, I also received another opinion on this same section of EB>my original article: EB> EB> "It seems to imply that strongly-typed languages are never EB> associated with dynamic binding: but C++, Trellis, Eiffel, and EB> Modula-3 are clearly strongly-typed and support dynamic EB> binding. (One place where binding may have been discussed is EB> in the functional programming community, where a function EB> variable is "dynamically bound" in contrast to a static EB> function reference. Even C supports dynamic binding through EB> function pointers.)" This is not another opinion. It supports my point. ----------a lot of stuff deleted------------- EB>You get half credit (;-)). I am biased. (Horrors! :-)) However, I am EB>biased in your direction. I tend to agree strongly with you that EB>strong typing is more important in large and critical applications. Ok good, but going back to the original topic again "evaluation of OOPLs", I don think strong typing should be regarded as a discriminating feature of OOPLs. Even the highest authority there is on the subject of language classification, Wegner himself :-) classifies both Simula and Smalltalk as OO. Thus the fact that a language is classified as OO says relatively little about how useful it is in a particular problem situation. --------------------------------------------------------------------- Anders Bjornerstedt E-mail: anders@cuisun.unige.ch Centre Universitaire d'Informatique 12 rue du Lac, CH-1207 Geneva --------------------------------------------------------------------- Tel: 41 (22) 787.65.80-87 Fax: 41 (22) 735.39.05 Home: 41 (22) 735.00.03 Telex: 423 801 UNI CH ---------------------------------------------------------------------
eberard@ajpo.sei.cmu.edu (Edward Berard) (01/11/90)
In article <753@cui.unige.ch>, anders@cui.unige.ch (BJORNERSTEDT Anders) writes: [...] > Anyway I don't want to get into a useless debate on the differences and merits > of Simula and Smalltalk. I was mainly concerned with the history of > "oo-concepts", and strong typing. When you say > that there are "missing" features in Simula which some regard as essential > to an object-oriented language, I would be interested in hearing what > those features are. Not because I want to enter the black hole of > how we should define "OO", but because I suspect that many people > are not familiar with Simula and possibly do not understand what > features it has. Like yourself, I have no interest in such a "useless debate." Until now, I was quite happy to say that some in the object-oriented community considered Smalltalk to be the first "true" object-oriented programming language, and these many of these same people considered Simula an "immediate precursor" to object-oriented programming languages. However, this conversation has made me re-think my viewpoint. Specifically, having re-examined my Simula and Smalltalk texts, I tend to agree with you. While I would still argue that the term "object-oriented" seems to have originated in the Smalltalk efforts, that does _not_ mean that any programming language which pre-dates Smalltalk is not "truly object-oriented." I too, would be interested in hearing from anyone with a different viewpoint, i.e., that Simula is somehow not "truly object-oriented." [...] > AB>> I would argue that types are an old concept in object-oriented programming... > EB> > EB>Here you have me, sir. By not being more precise than I was, I have > EB>left myself wide open. I could argue your point by citing a classic > --------Deleted discussion on definition of typing------------------ > > I think you misunderstood me. I was not trying to be an obnoxious > philosopher claiming that Smalltalk is typed in some sense. > I agree that typing is a "new" topic with respect to Smalltalk. > What I meant was simply that Simula is strongly typed (according to > all reasonable definitions of strong typing (give me a break here)). > and hence types are not a new concept in OOP. You are right -- I did misunderstand you. Further, when you said, "Strong typing and 'dynamic binding of method' are theoretically _orthogonal_.", I read "orthogonal" (i.e., being completely independent of each other), and thought "mutually exclusive." I admit that upon a second reading, I saw my mistake. While I will grant that some strong typing schemes may "get in the way of dynamic binding," I will also state that strong typing and dynamic binding are hardly mutually exclusive. [...] > > Ok good, but going back to the original topic again "evaluation of OOPLs", > I don't think strong typing should be regarded as a discriminating feature of > OOPLs. I fully agree. I think that I was not clear enough in the first part of my original article. The intent was to to say that: - The criteria for judging whether a programming language is object-oriented seem to vary widely, with few people (e.g., Wegner) taking the time to express their criteria in detail. - For each candidate criterion there appear to be a number of "exceptions." Specifically, given a criterion (e.g., classes), there is at least one "object-oriented programming language" which "violates" the criterion (e.g., Self). - Many people fail to attach weights to each criterion, i.e., all criteria are equally important. Thank you for the discussion. -- Ed Berard (301) 353-9652
rmz@jamhog.uio.no (Bjoern Remseth) (01/12/90)
> I too, would be interested in hearing from anyone with a different > viewpoint, i.e., that Simula is somehow not "truly object-oriented." I can think of two things: First of all there are a number of fundamental things that are not "true" classes, most notably all the numbers and texts. This basically means that even if they are there, and have a clearly defined protocol, a simula programmer can not make subclasses of them. Secondly it is possible to "INSPECT" any class instance. This means that one can look into and modify the state of an object as if it was a part of the local execution environment. Since identifiers local to the inspected object are used without any form of prefix it is not possible only by looking at a statement inside the inspect statement to see if it sends a message to an object or not. BEGIN CLASS foo; BEGIN INTEGER bar; END; REF (foo) f; f :- NEW foo; INSPECT f do BEGIN ! Note that "bar" is not declared on this block level, it is imported from the "f" object; bar := 200; OutInt(bar,10); OutImage end; END; -- (Rmz) Bj\o rn Remseth ! Net: rmz@ifi.uio.no Institutt for Informatikk ! NeXTmail: rmz@neste.uio.no Universitetet i Oslo, Norway ! Phone: +472 453466
sakkinen@tukki.jyu.fi (Markku Sakkinen) (01/12/90)
In article <RMZ.90Jan12020729@jamhog.uio.no> rmz@jamhog.uio.no (Bjoern Remseth) writes: > >> I too, would be interested in hearing from anyone with a different >> viewpoint, i.e., that Simula is somehow not "truly object-oriented." > >I can think of two things: > >First of all there are a number of fundamental things that are not >"true" classes, most notably all the numbers and texts. This >basically means that even if they are there, and have a clearly >defined protocol, a simula programmer can not make subclasses of them. Note: This criterion applies likewise to most (if not all) OOPL's that are extensions of conventional languages: Flavors, C++, Objective-C, CLOS, ... But I tend to agree that they are best regarded as "partially object-oriented". Question: However, isn't it actually bogus that all fundamental things in _Smalltalk_ are first-class objects? For instance, how do you define a use a meaningful subclass of SmallInteger, adding at least one instance variable? (This is not a rhetorical question: I have not used Smalltalk in practice and would be interested to see an example.) >Secondly it is possible to "INSPECT" any class instance. This means >that one can look into and modify the state of an object as if it was >a part of the local execution environment. Since identifiers local to >the inspected object are used without any form of prefix it is not >possible only by looking at a statement inside the inspect statement >to see if it sends a message to an object or not. > [example deleted] True, although in current Simula this can somehow be prevented by 'protected' (and 'hidden') declarations. Only in very few languages is the encapsulation of objects as tight as in Smalltalk. One can argue whether exactly the Smalltalk model is the only right one: there are good reasons for taking as the unit of encapsulation, either the object (as in Smalltalk) or the class (as in most other class-based languages). As compared at least to C-based OOPL's, Simula has the advantage that any protections established on the O-O level cannot be simply circumvented on the lower level. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland