Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.object Subject: Evaluating "Object-Oriented" Programming Languages Keywords: object-oriented, programming languages, evaluation, bibliography Message-ID: <638@ajpo.sei.cmu.edu> Date: 3 Jan 90 03:18:09 GMT Lines: 905 "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.