On the Notion of Object

J. SYSTEMS SOFTWARE 1993; 21:3-16

On the Notion of Object

Antero Taivalsaari University of Tampere, Tampere, Finland

As in science in general, in computer science there is a desire to unify general concepts. The notion of object has recently emerged as a promising answer to such desires. This article examines the seemingly simple notion of object from conceptual, philosophical, data abstraction, implementation, and formal viewpoints. We hope to provide new insights into what objects in object-oriented programming are, and an extensive literature analysis on the subject.

1. INTRODUCTION

Only the same reason is shared by all of us: we wish to create worlds as real as, but other than the world that is.

-John Fowles, The French Lieutenant’s Woman

Object-oriented programming emanated from the programming language SIMULA 67 [l-4], originally targeted for discrete-event simulation. SIMULA 67, later known simply as SIMULA [4], introduced most of the currently used features of object-oriented programming and had most of them right. However, for several reasons, SIMULA did not immediately gain acceptance save in certain academic communi- ties. In general, SIMULA was probably much ahead of its time, considering that not even the structured programming revolution had occurred at the time of its introduction. Nevertheless, SIMULA has since served as a valuable source of ideas in several research areas in computer science. Some of the sig- nificant research areas that have borrowed ideas from SIMULA include

1. abstract data types, pioneered by Liskov and Zilles [5, 61, Morris [7, 81, and Pamas 19, 101 in the early 1970s;

2. frames in artificial intelligence (based initially on work by Minsky [ll, 121);

Address all correspondence to Professor Antero Taivalsaari, Dept. of Computer Science, Uniuersity of Tampere, SF-33101 Tampere, Finland. 7?zis paper was written while the author was visiting the Universi~ of Victoria, Victoria, B.C., Canada.

0 Elsevier Science Publishing Co., Inc. 655 Avenue of the Americas, New York, NY 10010

3.

4.

semantic data models, first suggested by Hammer and McLeod [13, 141; (roots of this research lead back to [15]); and

capability-based computer systems (the foundations for this research were actually outlined before the inception of SIMWLA in the late 1950s but the notions of capability and object were not introduced until the end of the 1960s [16-B].

In return, work in many of these areas has consequently had a considerable impact on the further development of object-oriented programming. How- ever, this exchange of ideas has caused the less pleasant result that the terminology of object-oriented programming is very diverse. One contributor to this diversity of concepts is SMALLTALK [ 19,201 -the archetype of today’s object-oriented languages -which introduced more intuitive names to many of the central notions in object-oriented programming. Although this popularization made object-oriented programming more appealing to a wider audience, it did not necessarily make these concepts more un- derstandable.

Numerous introductory papers have been pub- lished in which the basic concepts and notions of object-oriented programming have been examined and defined [21-291. However, most of these papers concentrate only on one viewpoint or language in analyzing the various basic concepts. This article takes the opposite approach and focuses solely on the seemingly trivial notion of object from multiple viewpoints. I hope to offer new insights into what objects in object-oriented programming really are while providing an extensive literature analysis on the subject. This article is part of a larger study [30] in which the various elements of object-oriented programming, particularly the notion of inheritance, were studied in detail from multiple viewpoints.

Section 2 looks at different definitions of object- oriented programming. Section 3 focuses on the notion of object. The section is divided into five subsections, each of which examine a different view-

0164-1212/93/$6.00

4 .I. SYSTEMS SOFTWARE 1993; 21:3-16

point on the notion of object. Section 4 contains some concluding remarks.

2. OBJECT-ORIENTED PROGRAMMING

Object-oriented programming is like writing a fugue without having to build the piano.

-Advertisement in Computer Language

There does not really exist a single unanimously accepted definition of object-oriented programming. A general problem in defining object-oriented programming seems to be that object-orientation cannot be characterized simply as a set of certain language features; rather, it covers a wide spectrum of intertwined aspects ranging from implementation- level details to more vague conceptual modeling and systems design issues. Depending on what aspects and features are being emphasized, several different flavors or schools of object-oriented programming can be identified. For instance, as observed in many papers, there seems to be a contrast between Ameri- can and European approaches to object-oriented language design [28, 311.

The original motivation for the construction of SIMULA-the first object-oriented language ever-was to have a language particularly suited for discrete-event simulation [3]. With this in mind, it does not come as a surprise that from the beginning the Scandinavian inventors of SIMULA stressed the close correspondence between object-oriented programming and modeling. Consequently, a recurring tenet in most papers on object-oriented programming of Scandinavian origin has been that in object- oriented programming, programs should be regarded as “physical models, simulating the behavior of either a real or imaginary part of a world” [32, 331. The more closely the program resembles the world it is modeling, the better coherence between programming and conceptual modeling techniques can be gained, resulting in better understanding and easier maintenance of programs. The proponents of this viewpoint are often collectively referred to as the Scandinavian school of object-oriented programming [34, 351.

While seeing programs a conceptual models may be highly desirable, it has become evident that the correspondence between object-oriented programs and conceptual models is not often so straightfor- ward as one would desire. According to a more moderate and pragmatic standpoint, whose support- ers could be referred to as the American school, object-oriented programming is an approach that emphasizes the importance of data abstraction and

Antero Taivalsaari

reusability of program components. The followers of this approach often ignore the conceptual modeling potential of object-oriented programming and view it simply as a way to improve programming produc- tivity through easier reuse of program components.

Another dividing line in addition to the distinction between the European tendency toward aesthetic programming versus the American tradition of practical programming is to assess the object-oriented approaches and systems on the basis of their “radi- calness.” Some advocates of object-oriented programming, particularly those with a background in SMALLTALK programming, have often described object-oriented programming as a “revolutionaly” approach that is essentially different from traditional programming methodologies. For example, SMALLTALK introduced a new terminology for object-oriented concepts despite the fact that many of these concepts actually bear a close resemblance to traditional programming language constructs. On the other hand, as observed by Cox [21, 361, object- oriented programming may equally well be seen as a natural evolutionary step in the development of programming languages and techniques, in the same way as structured programming was an improvement over previous techniques and methodologies. Lan- guages such as C + + , Objective-C, and object PAS- CAL are good examples of such evolution.

Various definitions of object-oriented programming have been given in the literature. For example, Dittrich [371 has characterized object-oriented programming by identifying the following three levels of object-orientation:

Structurally object oriented: implies the capability of representing arbitrarily structured complex objects. Operationally object oriented: implies the ability to operate on complex objects in their entirety, through generic complex object operators. Behaviorally object oriented: implies typing in the object-oriented programming sense, with the specification of the types and operations (messages) which can manipulate objects of the given types, without the caller of the operator knowing the internal structure of the object being manipu- lated (data abstraction).

Booth [38] gives a typical “American” definition of object-oriented programming by defining it as “a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships.” Nier-


strasz [39] (from Switzerland) in turn contents him- self with a less restrictive definition by stating that the term “object oriented” is best interpreted as referring to any approach that exploits some form of “packaging.” A very similar definition can also be found in an older paper [40], in which object orientation is described as “a method for organizing software where, at any time, computation is performed under the aegis of a particular object.”

However, the only rather widely accepted general characterization of object-oriented programming is that it is something that is composed of two essential but more or less vague concepts [41-431:

Object-oriented programming = abstract data types

+ inheritance.

Several variations of this definition exist. For example, Wegner [44, 451 extends this definition by asserting that classes are a vital feature of object- oriented systems (see also Booth [38], p. 36):

Object-oriented programming

= data abstractions + object classes

+ class inheritance.

It is also rather generally accepted to distinguish between two basic forms of object-oriented systems. In addition to object-oriented systems defined as above, it is common to speak of object-based systems. An object-based language features some form of instantiatable objects or abstract data types, but lacks inheritance. According to these basic definitions, an object-oriented language is thus always object based, but the reverse is not true. Tello [46] has given a very appropriate practical definition of object-based programming: “. . . [it] is a type of programming that provides a way of modularizing programs by establishing partitioned memory areas for both data and procedures that can be used as tem- plates for spawning copies of such modules on de- mand.” For a more thorough discussion on different variations of object-related systems, see recent papers by Wegner 128, 45, 471.

Actually, the assertion that abstract data types are a prerequisite for object-based or -oriented systems may in many cases be overly restrictive. As will be discussed in more detail in section 3.3, objects in object-oriented systems cannot necessarily be regarded as true abstract data types. Furthermore, not all object-oriented systems feature classes. In fact, the purest object-oriented languages at the moment are based on prototypes rather than classes. The best-known of these prototype-based languages is probably SELF [48-511. Therefore, I would suggest the following, less restrictive definition of object-oriented programming:

J. SYSTEMS SOFTWARE 5 1993; 21:3-16

Object-oriented programming = objects

+ inheritance.

The key focus in this article is on the notion of object, and thus other issues such as inheritance will be ignored. For a more comprehensive multiview- point analysis of other basic concepts of object-oriented programming, including inheritance, see Taivalsaari [30].

3. FIVE VIEWS OF OBJECTS

You don’t understand anything until you learn it more than one way.

-Marvin Minsky

In science there is always a desire to unify general notions, concepts, and theories. Computer science is no exception, and recently the notion of object has been widely touted as a promising answer to these desires. The notion of object is not quite as simple as is often presented, though; in this section, it will be examined from the following five different viewpoints:

1.

2.

3.

4.

5.

Conceptual (modeling) viewpoint: object as a conceptual model of some part of a real or imaginary world. Philosophical viewpoint: object as an existential as opposed to universal abstraction. Software engineering or data abstraction viewpoint: object as a module (a collection of encapsulated operations and variables and other language constructs). Implementation viewpoint: object as a contiguous structure in memory, possibly containing or referring to other similar structures. Formal viewpoint: object as a graph of interre- lated state machines.

Obviously, these viewpoints are not totally orthogonal, but may overlap somewhat. Nevertheless, the division seems to be useful in analyzing the essence of objects. In particular, the philosophical viewpoint is typically ignored in the literature of object-oriented programming, even though the notion of object was a subject of study in philosophy (to be precise, ontology) for centuries before the advent of object-oriented programming.

3.1 Conceptual View

As regards the primary substances, it is indisputably true that each of them signifies a certain “this”; for the thing revealed is individual and numerically one.

-Aristotle, Categories

6 J. SYSTEMS SOFTWARE 1993; 21:3-16

According to the traditional Scandinavian view of object orientation, an object-oriented program consists of individual but cooperating components-objects-that represent the abstract concepts or concrete entities of a real or imaginary part of a world [33]. Seen from this viewpoint, an object can thus be generally characterized as a conceptually distinct unit that has some abstract significance to the users of a system, and that serves as a model of some particular concept in the real or imaginary world. The two most important aspects of an object from the viewpoint of conceptual modeling [52] are

1. its identity, which distinguishes the object from all other objects, and

2. its substance: the properties that hold for the objects and can be discovered by investigation of the object.

Note that there is a surprising analogy between object-oriented programming in the above sense and the classical philisophical Aristotelian view of the world. In both approaches, reality is viewed funda- mentally as composed of objects and properties associated with the objects. For a discussion on Aristo- tle’s ontological view of the nature of reality, see Barnes ([53], pp. 8-131, Evans ([54], pp. 61-81), and Kaila ([55], pp. 55-72).

According to a slightly more pragmatic definition, objects may be regarded as implementations of abstract data types that collect operations acting upon specific kinds of data into conveniently manageable packages. Each object consists of a mutable state usually represented recursively by other objects (denoted as variables) that is typically accessible only via the predefined interface of the object, specifying the behavior of the object-that is, the operations (often also referred to as methods) that can be invoked in order to inspect or modify the state of the object. In contract to traditional procedure-oriented programming languages where programs are regarded as action sequences, object-oriented programs are collections of interdependent components, each providing a service specified by its interface [28].

Briefly, an object is a collection of three aspects [38, 45, 473: object = identity + state + behavior, or object = identity + variables + operations.

The variables and operations of an object are usually collectively referred to as the properties of the object. Note that the properties must usually always reside in some particular object. That is, no such operations can exist that do not belong to some object (CLOS-the common LISP object system-is

Antero Taivalsaari

an exception to this practice). Object-oriented programming deemphasizes the procedures, stressing instead the grouping together of data and procedural features. Objects give group operations the data they will transform and provide a data-oriented principle for program design [26, 471.

Object identity is that feature of an object that distinguishes it from all other objects [38, 561. Object identity has several important characteristics which can be summarized as follows (adapted from 128, 41, 56-601):

Identities are atomic, unstructured units. That is, theoretically, there is never a question of how many machine-dependent storage cells an identity occupies.

Identities are purely information free. They do not imply anything about related objects nor any kind of meaningful ordering.

Identitites are globally unique and have the same format for all objects.

Identity persists over time independently of changes in the state of the object; that is, an object’s identity is logically distinct from its state and behavior.

Users do not specify the format, syntax, structure, or uniqueness rules for identities.

Identity is intended to be in one-to-one correspondence with some object which it is denoting; in contract, the correspondence between identifiers (names) and objects is often many to many.

From a more practical viewpoint, identity may viewed simply as an immutable tag, address, or a pointer to a memory location that uniquely identifies each object among all the objects in the system. In concrete terms, identity can be described as follows: two objects are alike in every way except that they oc- cupy different regions of memory [591. In this sense, the notion of identity is analogous to the notions of I value in programming language research or surro- gate in data base research.

The broadest possible definition that we can give to an object is that it is “anything that can be associated with a unique identifier” [61]. The most precise generally applicable definition we can come up with is the following: an object is a uniquely identifiable, reproducible collection of operations acting upon certain (kind of) data represented usually recursively by other objects, cooperating with other objects by a uniform mechanism typically known as message passing. By “reproducible” we mean that it should be possible to create a finite

On the Notion of Object J. SYSTEMS SOFTWARE 7 1993; 21%16

number of similar objects. Message passing refers to some mechanism which objects use to invoke each others’ properties. The mechanism may vary from system to system; the only common denominator seems to be that objects must have some way to communicate [451.

3.2 Philosophical View

Phaedrus remembered Locke’s statement that no object, scientific or otherwise, is knowable except in terms of its qualities. This irrefutable truth seemed to suggest that the reason scientists cannot detect Quality in objects is because Quality is all they detect. The “object” is an intellectual construct deduced from the qualities. This answer, if valid, certainly smashed the first horn of the dilemma, and for a while excited him greatly. -Robert M. Pirsig, Zen and the Art of Motorcycle

Maintenance Now of actual things some are universal, others particular.

-Aristotle, De Interpretatione

Let us now examine the notion of object from a more philosophical viewpoint. An often heard statement from the proponents of object-oriented programming-especially those whose background is in SMALLTALK programming-is that “everything is an object.” This statement reflects the ideal that object is a concept capable of serving as a general unifying notion underlying all computation. How- ever, this statement is in contrast with conventional philosophical wisdom.

Table 1. Objects and Values

From the viewpoint of conceptual modeling and ontology in particular, it can be argued that it is not reasonable to assume everything to be an object. Rather, there seem to exist two quite different types of abstractions. Some kinds of entities have a natural beginning and ending, whereas others have an “eternal” existence; creation and destruction are not relevant concepts for them. The latter tends to be true of what we call “concepts’‘-numbers, dates, colors, distances, masses. At the other extreme, there are tangible physical objects which have a well-defined finite period of existence, a beginning and an end; creation and destruction are very relevant concepts for them [57]. The “eternal” abstractions are usually known as values (universals, ideals) and the tangible ones as objects. Table 1 illustrates the distinction between objects and values. For further information, see [57-59, 62-641. In brief, values are universal abstractions, and hence atemporal, un- changeable, and noninstantiated; they can be used to denote mental (for example mathematical) constructs. Some researchers have even gone so far as to claim that, in a strict sense, values cannot exist in computers [59]: from the philosophical point of view, computers are strictly nominalistic devices capable of storing physical, existential things, but unable to store abstractions in the strict Platonic sense. Using some encoding however, values can be represented in computer memory [59, 631.

Objects, in turn, are existential abstractions that, to be meaningful, must first be bound to a particular representation. Objects may correspond to real world

Objects Values

Objects are existential They can be instantiated They can be copied They can be shared

Objects have a mutable state They can be changed They do not inherently preserve referential transparency

Objects possess temporal traits They have a lifetime They can be created and destroyed In order to exist they must be first constructed

Objects possess spatial traits They have a location They have size and structure

Objects have an identity They can be identified independently of their state Two objects can have the same form, but different substance

Objects have intension and extension It is feasible to distinguish behveen the description of an object and the object itself Objects may have different kinds of implementations

Values are universal They cannot be copied They cannot be counted It is not meaningful to talk about sharing of values

Values are immutable They are read only They preserve referential transparency

Values do not possess temporal traits They are atemporal (eternal) They cannot be created and destroyed They cannot really be constructed, but they are in a sense “found”

Values do not possess spatial traits They do not have a location They do not have size or structure

Values do not have identities They can be identified only through their extensional characteristics

Values are inherently extensional It is not meaningful to distinguish between the description of a value and the value itself Values are one-of-a-kind (singular) abstractions


entities; hence, they exist in time, are changeable, have state, are instantiated, and can be created, destroyed, and shared [57, 591. Compared to values, which are referentially transparent (see below), objects are thus usually referentially opaque. Objects can nonetheless be used to represent values encoded to some particular representation [63]. The notion of referential transparency stems from philosophy [65, 661, where it was originally used to refer to the substitutivity of identities: that is, the interchange- ability of two expressions denoting the same thing. In programming the notion of referential transparency is often used in a slightly different meaning. In the terminology of functional programming, in particular, referential transparency typically implies freedom from side effects: a (mathematical) function should always return the same value for the same arguments [67-691.

Although the dichotomy between objects and values may be too philosophical to be of practical use in computer science, it is intriguing in analyzing the foundations of object-oriented programming. As observed by Wegner 145, 471, objects may well be seen as the opposite of functions, which have no memory. Whereas function values are completely determined by their arguments, an object may learn from experi- ence, its reaction to an operation being determined by its invocation history. In general, object-oriented programming may be regarded as the antithesis of functional programming. Whereas immutability and the lack of identity are characterizing features of functional programming, strong object identity and mutable object state are essential features of object-oriented programming. Moreover, whereas functional programming represents an approach to programming that is founded upon value semantics, object-oriented programming, in its purest form, should be based on full reference semantics (see [59]; the notions of value and reference semantics will be explained in subsection 3.4).

Despite the inherent discrepancy between object- oriented and functional programming, there have appeared some attempts to construct functional object-oriented languages. Indeed, both functional and object-oriented programming approaches share some common objectives; one such objective is the aspira- tion to raise the level of abstraction in programming through the use of abstract data types. However, functional object-oriented languages, such as FOOPS [70], possess features that are quite different from conventionally object-oriented ones. A good example of how differently object-oriented programming can be interpreted from the viewpoint of logic programming can be found in Banchilhon [71]. Many

Antero Taivalsaari

purist proponents of object-oriented programming do not consider these systems truly object oriented.

It can be stated that the notion of object differs considerably in different language subcultures and it is important to distinguish them. Wegner [28] has given the following categorization of objects (see also Agha et al. [72]):

Functional objects have an objectlike interface but no updatable state and no identity. Functional objects do not change state but instead “become new objects.”

Imperative objects have an updatable state shared by operations in the interface.

Active objects have the ability to act on their own. Active objects may already be active when receiv- ing a message, so that incoming messages must synchronize with ongoing activities of the object.

This article focuses mainly on imperative objects.

3.3 Data Abstraction View

Guaranteed abstraction is guaranteed peace of mind. -Daniel Halbert

A typical definition of object-oriented programming is that it is something that is characterized by two central notions: abstract data types (ADTs) and inheritance [41-431. Similarly, one often hears that “objects are encapsulated data abstractions” [73], or that objects (classes) are implementations of ADTs [74, 751. However, it appears that both of these notions-ADTs and inheritance-are far from being unanimously accepted. This subsection discusses in what respect is it justifiable to treat objects as data abstractions.

In general, the term “abstraction” usually refers to the principle of ignoring those aspects of a subject that are not relevant to the current purpose in order to concentrate solely on those that are. In other words, abstraction strives to suppress all details about some object (or activity) except for those that are relevant to the understanding of some phenomenon of interest [68, 761. Correspondingly, an abstraction is a simplified description, or specification, of a system that emphasizes some of the system’s details or properties while suppressing others [77].

Abstraction seems to bear an inherent intimate relationship to conceptual modeling. Abstraction is a way to exploit regularity in what we observe in order to construct realistic but rigorously defined and reasonably manageable conceptual models of real-world or imaginary phenomena. Without abstraction, one could easily drown in the overwhelming complexity

On the Notion of Object J. SYSTEMS SOFTWARE 9 1993; 21:3-16

of real-world and other large systems. As stated by Brooks [78], complexity is an essential property of large systems, not an accidental one; it should not be regarded as a tlaw in design, but as an inherent, inescapable feature of large systems [381.

The notion of abstraction was not completely un- known even in the earliest programming languages. Early programming languages supported abstraction in the form of procedural (or functional) abstraction, by which we refer to the principle that any operation that achieves a well-defined effect can be treated by its users as a single entity, despite the fact that the operation may actually be achieved by some se- quence of lower level operations [68, 791.

Parnas [91 took the first steps toward the notion of data abstraction in a paper that introduced a precur- sor of the syntax to be used in the ensuing research into ADTs. There are other important early papers germane to the subject [5-8, 10, 801. According to the principles formulated by these and other researchers in the early 1970s every “good” programming system and style should strive to achieve two essential general ideals: locality of information and representation independence.

The first ideal-locality of information-suggests that a good programming system should try to keep related pieces of behavior and data in the programs adjacent to each other. This objective was satisfied by objects in SIMULA but not by languages supporting only procedural abstraction. This ideal gave rise to the introduction of modules into programming languages [8-101. The second ideal-representation independence (also known as the information-hiding principle or representation abstraction)-implies that a good programming style should ensure that components in the system make as few assumptions as possible about the other components in the system. In other words, a program should be designed so that the representations (implementations) of components do not affect the rest of the program [8, 79, 81, 821. This ideal emphasizes the importance of separating two divergent aspects of abstractions: logical definition (specification) and physical implementation (representation) [5, 6, 61, 83, 841. Ideally, specifications should correspond to real-world abstractions and hide details the user wants to ignore momentarily in thinking about the real world, whereas implementations hide details the user never wants to see about the actual data structure implementation [76]. Specification interposes between the concept and its implementation and bars the exter- nal world from manipulating the internal implementation-level aspects of the abstraction, thereby pre- venting undesired side effects which may result when

distinct parts of a program manipulate the same objects.

Generally, data abstraction can be defined as the principle of defining a data type in terms of the operations that apply to objects of the type, with the constraint that the values (- state) of such objects can be modified and observed only by the use of the operations [68]. By a data type in this context we refer simply to a set of objects and a set of operations on these objects [63, 851. In particular, an ADT defines a class of objects completely characterized by the operations available on those objects [5; see also 6, 42, 45, 63, 861: the programmer is concerned only with the behavior which that object exhibits but not with any details of how that behavior is achieved by means of an implementation 1861. Another often employed term is data structure, which refers to a data type whose representation is directly manipu- latable (no representation independence) 1871. A synonym for data structure is concrete type, that is, “based on a particular choice of representation for the entities being modeled, and determined by the applicability of specific operations” [52]. Note that these are not the only possible ways to define the notion of ADT. In some references, ADT is defined simply as a user-defined data type [85] or a collection of data structures and operations abstracted into a simple data type [88].

Although often claimed to the contrary, it can be argued that in object-oriented programming, objects are not necessarily always data abstractions. SIM- ULA-the first object-oriented language-supported the principle of locality of information but did not originally facilitate representation independence; nevertheless, SIMULA is usually considered object oriented [45]. Also, many object-oriented languages of today (SMALLTALK, for instance) do not really support separation of specification from implementation, apart from the fact that in these languages it is possible to define abstract classes that serve as partial implementations. In fact, several years ago Shaw 1771 characterized the distinction between object-oriented and ADT programming by asserting that whereas the ADT approach emphasizes the separation of specification and implementation, object-oriented programming does not. How- ever, this distinction has since become blurred, as both approaches have adopted ideas from each other. Nevertheless, it may be legitimate to claim that objects and data abstraction are indeed somewhat orthogonal (independent) dimensions. For example, as observed by Fiadero and Maibaum [64], most of the work on the formalization of ADTs has been developed around the notion of values as opposed to


Antero Taivalsaari

objects. The key factor that makes a data type abstract is rather independent of whether the system in concern is based on a value- or object-oriented perspective. Both approaches can foster the principles of data abstraction. For an interesting recent discussion on object orientation versus ADTs refer to Cook [89]. Encapsulation, a mechanism to pro- mote data abstraction and information hiding in the context of object-oriented programming, has been studied in detail [42, 90, 911.

3.4 Implementation View

But there is yet another consideration which is more philosophical and architectonic in character; namely to grasp the idea of the whole correctly and thence to view all . . . parts in their mutual relations.

--I. Kant, Preface to the Critique of Practical Reason

From the technical point of view, objects may be regarded as collections or records of named properties denoting data or code, each property being also an object itself. An object can be composed of several other objects also capable of possessing further subobjects. Objects that possess other objects can be called aggregate or composite objects. Some- where down at the bottom there are then rock-bottom objects, which cannot be divided into further subobjects; these are usually called atomic or primitive objects 1631. An atomic object typically denotes a single, logically undecomposable concept such as a character, an integer, a Boolean truth value or a piece of program code. Aggregate objects are collections of other aggregate or atomic objects. Basically, all different kinds of objects are implemented as byte vectors with some embellishments.

The issue of how objects possessed by aggregate objects are actually represented appears to be most intricate in the implementation of object-oriented systems. The object-oriented programming paradigm is based essentially on sharable, mutable objects, so that unlike in functional programming, where ques- tions related to state, storage, or memory can simple be ignored, the question of storage model must be taken into serious consideration. Depending on the storage model adopted in the system, objects possessed by aggregate objects may be either contained in or referred to from the aggregate objects, causing differences in the higher level semantic characteristics of the system. Let us now briefly investigate the classical storage models that can be used to imple- ment memory management in programming languages. For further information, see [63, 921.

Value semantics is perhaps the simplest scheme in implementing storage management. Value semantics

provides no concept of sharing, pointers, or call by reference [63]. Objects are contained in memory directly as contiguous vectors of bytes; no references to other objects are allowed. Because the model dispenses with references, all aggregate objects must be represented basically as linear aggregates (Figure la). Value semantics does not allow sharing of objects, so it is most suited to functional programming systems or other systems where all data are immutable--to be more precise, for systems which exhibit referential transparency (see below). In such systems, copying of data is semantically equivalent to sharing [59], so the lack of sharing causes no limita- tions in expressive power. However, if mutable objects are needed, then value semantics will fall short in its ability to represent arbitrary aggregate objects because of the lack of sharing. As sharable, mutable objects are indispensable in object-oriented programming, we can conclude that value semantics is inadequate for implementing such systems.’

Reference semantics (or pointer semantics) is the opposite of value semantics. Pure reference semantics presumes that all data are represented either by atomic objects or by pure reference aggregates (Fig-

data/code djc data/code

(a)

A

I (b)

4

I data/code / 1 data/code

Cc) Figure 1. Aggregate object structures. (a) linear aggregate; (b) pure reference aggregate; (c) mixed aggregate.

’ Actually, it is possible to distinguish two forms of value semantics. From the conceptual viewpoint, value semantics does not absolutely necessarily require that pointers are not used. The only requirement is that, to the user, the storage system appears as supporting only immutable pointerless structures. However, references might be used at the implementation level for efficiency. By the term “containment semantics” we refer to such a storage scheme in which references are not used even at the implementation level.

On the Notion of Object J. SYSTEMS SOFTWARE 11 1993; 21%16

me lb). Aggregate objects are simply collections of references to other objects. All the objects in the system are individual in the sense that they are associated with a unique identity and are located physically independent of other objects in the system. As a result, the scheme enables flexible sharing of objects by reference passing. Moreover, for the same reason, the scheme also facilitates garbage collection and is suitable for systems in which the sizes of objects change frequently. At first glance, reference semantics appears as a natural, ideal choice for systems featuring sharable, mutable objects such as object-oriented systems typically are. But alas, reference semantics can easily lead to less efficient language implementations because it (in its purest form) assumes that even the most primitive objects, such as characters and integers, must be represented as separate objects. Furthermore, reference semantics can lead to some unexpected behavior with atomic literal objects [63, 93, 94; see also 571. In general, aliasing can pose problems with reference semantics. SMALLTALK [19, 201 is an example of a language using reference semantics, although even SMALLTALK uses some optimiza- tions to speed up atomic object management. An interesting early language to experiment with reference semantics is GEDANKEN [7, 921.

Value and reference semantics models both possess several nice, aesthetically pleasant characteristics. However, both models are rather extreme. In practice the most commonly employed storage model in programming languages is storage semantics [63]. Storage semantics allows representation of aggregate objects both by containment and references, whichever appears to be more appropriate for each particular structure. Aggregate objects can contain other objects directly, refer to other objects, or do both at the same time; such aggregates can be called mixed aggregates (Figure lc). Storage semantics of- fers a pragmatic and efficient compromise between value and reference semantics; in fact, it is so commonly used in normal imperative languages such as C or PASCAL that we rarely even think about the possibility of having more pure schemes in such languages. Unfortunately, object-oriented languages feature much more complicated fundamental operations on complex objects than conventional languages. As a result, storage semantics can plunge us into problems that are difficult to resolve. Examples of basic operations that may become tricky in the presence of storage semantics are copying, destruction, comparison, or other similar operation that, depending on the particular situation, must or must not be propagated to the subobjects of an aggregate

object [56]. Consider shallow copying, for instance. Shallow copying is a form of copying in which only the surface level of an aggregate object (but not the component objects) is copied. If we try to shallow copy a stack object whose elements are stored in an array object referred to from the stack but whose stack pointer is contained directly in it, the result is another stack that shares the elements of the original stack, yet both stacks have their own stack pointers! Value or reference semantics pose no problems in similar situations, because in those schemes, the behavior of copying operations can always be antici- pated without knowing the physical structure of the object to be copied. In general, storage semantics seems to introduce an unpleasant confusion between references and their contents [93]. Problems and solutions pertaining to such issues have been addressed elsewhere [56, 83, 95, 961. A good example of an object-oriented language that allows almost unlimited combination of containment and pointer semantics is C + +.

It is not easy to select a suitable object-storage model for an object-oriented language. It seems that the choice of a storage model cannot be made fully transparent, but always to some extent affects the system’s high-level characteristics. Basically, reference semantics seems to be the most appropriate choice, but on the other hand, storage semantics typically provides better efficiency. The issue is also reflected in the previously mentioned controversy between objects and values. Intuitively, it feels un- reasonable to represent primitive entities such as numbers and characters as separate objects. Note that the treatment of objects that are physically embedded within other objects as full-fledged first- class objects2 (see [451) might also be rather awk- ward. Therefore, mixing containment and references does not intuitively seem to be a right solution for storing objects in object-oriented systems. Most current object-oriented systems are based on reference semantics, with the exception what “reasonably small” atomic objects (such as numbers and characters) are usually embedded within aggregate objects by containment.

One further implementation-level aspect in object-oriented systems which should be mentioned is garbage collection. Since objects are temporal abstractions and have a lifetime, they will sooner or

* Objects are said to be first class when they may be assigned as values of variables, passed as parameters, and have a class that guarantees their status as computational values that can be managed by computation within the language 145, 691.


later be destroyed. In a system featuring mutable, sharable objects, explicit destruction of objects by the user would be undesirable or even hazardous, so automated mechanisms based on reachability of objects or other relevant aspects are usually introduced in object-oriented systems to take care of this implic- itly. Most important different methods of garbage collection include mark-and-sweep, reference count- ing, copying, and generation-scavenging techniques 1971. Garbage collection is a vast field of study in its own right, and will not be addressed further here. For good starting points on the subject, see [98-1001. Surprising, no good textbooks on garbage collection seem to be available.

3.5 Formal View

A mathematician is a machine for converting coffee to theorems.

-Anonymous

As noted by Fiadero and Maibaum [64], the popular- ity of the notion of object has not been accompanied by the necessary formalization of the concepts and constructions involved. In fact, there is a logical reason why no commonly accepted theory of object- oriented programming exists. Theories and formalisms should be based on a sound mathematical basis. Mathematical formalisms are essentially value based (section 3.2); concepts that are central to object-oriented programming such as state, updat- ing, and sharing do not naturally fit very well to such formalisms [591. While it is possible to carry state or model updates in a formal way, such approaches tend to seem a bit alien and futile to people with a more “imperative” background. However, some approaches to formalize the notion of object have been presented [64]. Formalization of objects has also been an active area of research in the field of specification languages. Here some considerations pertaining to the formalization of objects are presented, but the analysis is admittedly rather limited.

From the theoretical point of view, an object may be generally regarded as a state machine with a finite set of states and a finite set of functions that map old states and inputs to new states and outputs. Formally, an object can be defined as a four-tuple (I, T, u, N), where I denotes the identity of the object, T denotes the type of the object (or, more generally, the description that determines the behavior and structure of the object), u denotes the current state (value) of the object, and N denotes a set of names (identifiers) currently referring to the object.

Antero Taivalsaari

Each component in the four-tuple may be depicted as a certain kind of binding (Figure 2).3 Identity I binds the object to a unique location in storage space that holds the set of all objects in the system. Type T binds the object to a certain type in type space, the set of all object descriptions in the system. Value u (U E V) binds the object to a certain state that must be one of all the allowed states V for that object. The set v of all the allowed states, as well as the set of all operations and the set of all property names of the object, is determined by T. N, denoting the set of all such identifiers in the system’s identifier name space that currently refer to the object of concern, may seem rather irrelevant at first consideration. However, because the existence of an object would make little sense without some other objects in the system referring to it, N can be deemed relevant. Nevertheless, in some papers it is omitted; for example, Khoshafian and Copeland [56] depict objects simply as triples (I, T, u).

Identity binding I, is always constant during the lifetime of an object. Regardless of any changes in the properties of an object, the object’s identity will always remain the same. Similarly, type binding T is usually constant. However, in some systems, the sets of operations, states, and property names denoted by T can be modified dynamically. Such systems allow dynamic type modification. Furthermore, in a few object-oriented systems, the type of an object can indeed be dynamically changed to another type. Such systems support dynamic type changing. For a discussion on type modification and changing, see [lOl, 1021.

Type space

aclm vtibtcs I opn*ions

0:

4 Identifier (name) Storage space space

type value bmding bmdmg

identity bindmg

Figure 2. Formal view of an object.

3 Note that although for conceptual clarity the object storage, type, and identifier name spaces are depicted as separate in Figure 2, in reality they typically reside in the same physical memory space. The idea for Figure 2 was initially obtained from Dershem and Jipping [88].


The state u of an object may vary dynamically within the limits imposed by T. Objects whose state may change are called mutable. Alternatively, an object may be immutable. Immutable objects possess several characteristics that make them very useful. In particular, since immutable objects are read only, it is always safe to share them for efficiency. Owing to immutability, there is never any danger of one entity altering something which might be used by another [59]. In other words, immutable objects exhibit referential transparency.

Individual objects in object-oriented programs are often represented formally as records. This approach has been favored particularly by Cardelli [44, 1031 and Cook [104], or in the context of object-oriented databases by Zhu and Maier 11051. A comprehensive record notation for object representation has also been suggested [30].

In general, a record is a finite mapping from a set of names to a set of fields [681. In the context of object-oriented programming, a record (an object) may be viewed as a mapping from names to objects. Each element in a record, an identifier/object pair, maps one name (identifier) to some object (variable or operation). As a simple example of such notation, consider the following definition:

g, :- [P, :- 01, p2 :- 02, p3 :- 031.

This definition describes an object g, with three

properties pl, p2, and p3 that currently refer to objects o,, 02, and 03, respectively. Instead of using identifiers, or and o2 could naturally also be represented as records nested within record g,. Such a notation can obviously be used as a tool for describing arbitrarily complex object structures.

4. CONCLUSION

Object-oriented programming is a paradigm that emphasizes the meaning of data abstraction and reusability of program components. Object-oriented programs are composed of individual, cooperating components-objects-that can be viewed ideally as conceptually distinct units that have some abstract significance to the users of a system and that may possibly serve as models of some particular concepts in the real or imaginary part of a world. In this article, the seemingly trivial notion of object has been investigated from five different viewpoints. In addition to the normal conceptual view, I have looked at the notion of object from philosophical, data abstraction, implementation, and formal viewpoints. On the philosophical side, the controversial issue is the dichotomy between objects and values.

J. SYSTEMS SOFIWARE 13 1993; 21:3-16

From the data abstraction viewpoint, the relationship between objects and abstract data types is the main concern. From the implementation viewpoint, different semantics for storing objects were investigated. Finally, a more formal look at the notion of object was taken.

ACKNOWLEDGMENTS

This research was supported by the Academy of Finland under projects 1061120 and 8001552. I thank Markku Sakki- nen (University of Jyvlskyll, Finland), Kai Koskimies (Univer- sity of Tampere, Finland), Juha Vihavainen (University of Helsinki, Finland), Peter Grogono and Karen Tennenhouse (Concordia University, Montreal, Canada), Karl Lieberherr and Ian Holland (Northeastern University, Boston, Mas- sachusetts), Bjorn Freeman-Benson, Csaba Csaki, and Jan Vitek (University of Victoria, Canada) for helpful discussions.

REFERENCES

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

G. M. Birtwistle, 0. J. Dahl, B. Myhrhaug, and K. Nygaard, Simula Begin, Studentlitteratur, Lund, Swe- den, 1973. 0. J. Dahl, B. Myhrhaug, and K. Nygaard, SIMULA 67 Common Base Language, Norwegian Computing Center, Oslo, Norway, 1968. K. Nygaard and 0. J. Dahl, The Development of the Simula Languages (ACM SIGPLAN History of Pro- gramming Languages Conference), ACM SIGPLAN Not. 13, 245-272 (1978). R. J. Pooley, An Introduction to Programming in Simula, Blackwell, Oxford, England, 1987. B. H. Liskov and S. N. Zilles, Programming with Abstract Data Types (Proceedings of ACM SIG- PLAN Conference on Very High Level Languages), ACM SZGPLAN Not. 9, 50-59 (1974). B. H. Liskov and S. N. Zilles, Specification Tech- niques for Data Abstractions, IEEE Trans. Soj?ware Eng. 1, 7-19 (1975). J. H. Morris, Jr., Protection in Programming Lan- guages, Commun. ACM 16, 15-21 (1973). J. H. Morris, Jr., Types are not sets, in Conference Record of ACM Symposium on Principles of Program- ming Languages, ACM Press, New York, New York, 1973, pp. 120-124. D. L. Parnas, A Technique for Software Module Specification with Examples, Commun. ACM 15, 330-336 (1972). D. L. Pamas, On the Criteria to be Used in Decom- posing Systems into Modules, Commun. ACM 15, 1053-1058 (1972). R. Fikes and T. Kehler, The Role of Frame-Based Representation in Reasoning, Commun. ACM 28, 904-920 (1985). M. Minsky, A framework for representing knowledge, in The Psychology of Computer Vision (P. Win- ston, ed.), McGraw-Hill, New York, 1975, pp. 21 l-277.


Antero Taivalsaari

13. M. Hammer and D. McLeod, The semantic data model: A modeling mechanism for data base applications, in Proceedings of ACM SIGMOD International Conference on Management of Data, 1978, ACM Press, New York, New York, pp. 26-35.

14. M. Hammer and D. McLeod, Database description with SDM: A Semantic Database Model, ACM Trans. Data. Syst. 6, 351-386 (1981).

15. M. R. Quillian, Semantic memory, in Semantic Infor- mation Processing (M. Minsky, ed.), The MIT Press, Cambridge, Massachusetts, 1968.

16. J. B. Dennis and E. C. Van Horn, Programming Semantics for Multiprogrammed Computations, Commun. ACM 9, 143-155 (1966).

17. R. S. Fabry, Capability-Based Addressing, Commun. ACM 17, 403-412 (1974).

18. H. M. Levy, Capability-Based Computer Systems, Digi- tal Press, Bedford, Massachusetts, 1984.

19. A. Goldberg and D. Robson, Smalltalk-80: The Lan- guage and its Implementation, Addison-Wesley, Read- ing, Massachusetts, 1983.

20. A. Goldberg and D. Robson, Smalltalk-80: The Lan-

guage, Addison-Wesley, Reading, Massachusetts, 1989.

21. B. Cox, Message/Object Programming: An Evolu- tionary Change in Programming Technology, IEEE Sofmare 50-61 (January 1984).

22. J. Diederich and J. Milton, Experimental Prototyping in Smalltalk, IEEE Software 50-64 (May 1987).

23. B. P. Pokkunuri, Object Oriented Programming, ACM SIGPLAN Not. 24, 96-101 (1989).

24. T. Rentsch, Object Oriented Programming, ACM SIGPLAN Not. 17, 51-57 (1982).

25. D. Robson, Object-Oriented Software Systems, BYTE 6, 74-86 (1981).

26. M. Stefik and D. Bobrow, Object-Oriented Program- ming: Themes and Variations, AI Magazine 6, 40-62 (1986).

27. B. Stroustrup, What Is Object-Oriented Program- ming, IEEE Software lo-20 (May 1988).

28. P. Wegner, Concepts and Paradigms of Object-Ori- ented Programming. ACM OOPS Messenger 1, 7-87 (1990).

29. W. Wolf, A Practical Comparison of Two Object-Ori- ented Languages, IEEE Software 61-68 (September 1989).

30. A. Taivalsaari, Towards a Taxonomy of Inheritance Mechanisms in Object-Oriented Programming, Ph.Lic. Thesis, University of Jyvhkyla, Jyvbkyla, Finland, 1991.

31. Workshop on Object-Oriented Programming ECOOP ‘87 (Paris, June 18, 19871, ACM SIGPLAN Not. 23, 16-37 (1988).

32. J. L. Knudsen and 0. L. Madsen, Teaching object- oriented programming is more than teaching object- oriented programming languages, in ECOOP ‘88 Conference Proceedings, Lecture Notes in Computer Science 276, Springer-Verlag, New York, New York,

1988, pp. 21-40. 33. 0. L. Madsen and B. Moller-Pedersen, What object-

oriented programming may be and what it does not have to be, in ECOOP ‘88 Conference Proceedings, Lecture Notes in Computer Science 276, Springer- Verlag, New York, New York, 1988, pp. l-20.

34. 0. L. Madsen, B. Magnusson, and B. Moller-Peder- sen, Strong Typing of Object-Oriented Programming Revisited (OOPSLA/ECOOP ‘90 Conference Pro- ceedings), ACM SIGPLAN Not. 25, 140-149 (19901,

35. B. Magnusson, Tools ‘90 Conference Report, J. Ob- ject-Oriented Progr. 3, 73 (1990).

36. B. Cox, Object-Oriented Programming: An Evolution- ary Approach, Addison-Wesley, Reading, Mas- sachusetts, 1986.

37. K. R. Dittrich, Object-oriented database systems: The notion and the issues, in Proceedings of the 1986 International Workshop on Object-Otiented Database Systems, ACM Press, New York, New York, 1986.

38. G Booth, Object-Oriented Design with Applications, Benjamin/Cummins Publishing Company, Redwood City, California, 1991.

39. 0. M. Nierstrasz, A survey of object-oriented concepts, in Object-Oriented Concepts, Applications and Databases (W. Kim and F. Lochowsky, eds.), Addi- son-Wesley, Reading, Massachusetts, 1988, pp. 3-21.

40. G. Curry, L. Baer, D. Lipkie, and B. Lee, Traits: An Approach to Multiple-Inheritance Subclassing (Pro- ceedings of SIGOA Conference on Office Informa- tion Systems), ACM SIGOA Newslett. 3, l-9 (1982).

41. S. Danforth and C. Tomlinson, Type Theories and Object-Oriented Programming, ACM Comp. Suru. 20, 29-72 (1988).

42. B. H. Liskov, Data Abstraction and Hierarchy, (Ad- dendum to the Proceedings of OOPSLA ‘871, ACM SZGPLAN Not. 23, 17-34 (1988).

43. L. Power, ed., Panel Discussion: Object-Oriented Concurrency (Addendum to the Proceedings at OOPSLA ‘871, ACM SIGPLAN Not. 23, 119-127 (1988).

44. L. Cardelli and P. Wegner, On Understanding Types, Data Abstraction and Polymorphism, ACM Comp. Suru. 17, 471-522 (1985).

45. P. Wegner, The object-oriented classification paradigm, in Research Directions in Object-Oriented Programming (B. Shriver and P. Wegner, eds.), The MIT Press, Cambridge, Massachusetts, 1987, pp. 479-560.

46. E. R. Tello, Object-Oriented Programming for Artificial Intelligence: A Guide to Tools and System Design, Addison-Wesley, Reading, Massachusetts, 1989.

47. P. Wegner, Dimensions of Object-Based Language Design (OOPSLA ‘87 Conference Proceedings), ACM SIGPLAN Not. 22, 168-182 (1987).

48. C. Chambers and D. Ungar, Making Pure Object- Oriented Languages Practical (OOPSLA ‘91 Confer- ence Proceedings), ACM SIGPLAN Not. 26, l-15 (1991).


49.

50.

51.

52.

53.

54.

55.

56.

57.

58.

59.

60.

61.

62.

63.

64.

65.

C. Chambers, D. Ungar, and E. H.-S. Lee, An Effi- cient Implementation of Self, a Dynamically-Typed Object-Oriented Language Based on Prototypes (OOPSLA ‘89 Conference Proceedings), ACM SIG- PLAN Not. 24, 49-70 (1989). L. A. Stein, H. Lieberman, and D. Ungar, A shared view of sharing: The Treaty of Orlando, in Object- Oriented Concepts, Applications and Databases (W. Kim and F. Lochowsky, eds.), Addison-Wesley, Read- ing, Massachusetts, 1988, pp. 31-48.

D. Ungar and R. B. Smith, Self: The Power of Simplicity (OOPSLA ‘87 Conference Proceedings), 4CM SIGPLAN Not. 22, 227-241 (1987). S. N. Zilles, Types, algebras, and modelling, in On Conceptual Modelling: Perspectives from Artificial Intel- ligence, Databases, and Programming Languages (M. L. Brodie, J. Mylopoulos, and J. W. Schmidt, eds.), Springer-Verlag, New York, New York, 1984, pp. 441-450.

J. Barnes, ed., The Complete Works of Aristotle, vol. 1, Princeton University Press, Princeton, New Jersey, 1984, pp. 3-24.

J. D. G. Evans, Philosophers in Context: Aristotle, St. Martin’s Press, New York, 1987.

U. Kaila, Human knowledge: What It Is and What It Isn’t (Inhimillinen tieto: mitii se on ja mitt? se ei ale), Kustannusosakeyhtid Otava, Helsinki, Finland, 1939 (in Finnish).

S. N. Khoshafian and G. P. Copeland, Object Identity (OOPSLA ‘86 Conference Proceedings), ACM SIG- POiN Not. 21, 406-416 (1986).

W. Kent, Data and Reality, North-Holland, Amster- dam, The Netherlands, 1978.

W. Kent, A Rigorous Model of Object Reference, Identity, and Existence. J. Object-Oriented Progr. 4, 28-36 (1991). B. J. MacLennan, Values and Objects in Program- ming Languages, ACM SIGPD1N Not. 17, 70-79 (1982). T. Matsushima and G. Wiederhold, A Model of Object-Identities and Values, Stanford University Report STAN-CS-90-1304, Stanford, California, 1990.

C. H. A. Koster, Visibility and Types (Proceedings of Conference on Data Abstraction, Definition and Structure), ACM SZGPLAN Not. 11, 179-190 (1976). C. Beeri, A Formal Approach to Object-Oriented Databases, Data I&owl. Eng. 5, 353-382 (1990). J. C. Cleaveland, An Introduction to Data Types, Addison-Wesley, Reading, Massachusetts, 1986. J. Fiadero and T. Maibaum, Describing, structuring and implementing objects, in Foundations of Object- Oriented Languages (J. W. De Bakker, W. P. De Roever, and G. Rozenberg, eds.1, Lecture Notes in Computer Science 489, Springer-Verlag, New York, New York, 1991, pp. 274-310. W. V. 0. Quine, Word and Object, The MIT Press, Cambridge, Massachusetts, 1960.

66.

67.

68.

69.

70.

71.

72.

73.

74.

75.

76.

77.

78.

79.

80.

81

J. SYSTEMS SOFTWARE 15 1993; 21:3- I6

A. N. Whitehead and B. Russell, Principia mathemat- ica, 1910-1913 (2nd ed, 1925-1927).

P. Hudak, Conception, Evolution, and Application of Functional Programming Languages, ACM Comp. Suns. 21, 359-411 (1989).

Oxford Dictionary of Computing (3rd edition), Oxford University Press, Oxford, England, 1990.

J. E. Stoy, Denotational Semantics: The Scott-Strachq’ Approach to Programming Languages, The MIT Press, Cambridge, Massachusetts, 1977.

J. 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, eds.), The MIT Press, Cambridge, Massachusetts, 1987, pp. 417-477.

F. Banchilhon, A Logic Programming/Object-Ori- ented Cocktail, ACMSIGMOD Rec. 15,11-21 (19861.

G. Agha, P. Wegner, and A. Yonezawa, eds., Pro- ceedings of the ACM SIGPLAN Workshop on Ob- ject-Based Concurrent Programming, ACM SZG- PLAN Not. 24, 4 (1989).

P. S. Canning, W. R. Cook, W. L. Hill, and W. G. Olthoff, Interfaces for Strongly-Typed Object-Ori- ented Programming (OOPSLA ‘89 Conference Pro- ceedings), ACM SIGPLAN Not. 24, 457-467 (1989). T. Korson and J. D. McGregor, Understanding Ob- ject-oriented: A Unifying Paradigm, Commun. ACM 33, 40-60 (1990).

R. J. Wirfs-Brock and R. E. Johnson, Surveying Cur- rent Research in Object-Oriented Design, Commun. ACM 33, 104-124 (1990). J. M. Smith and D. C. P. Smith, Database Abstrac- tions: Aggregation, Commun. ACM 20, 405-413 (1977). M. Shaw, The impact of modelling and abstraction concerns on modern programming languages, in On Conceptual Modelling: Perspectives from Artificial Intel- ligence, Databases, and Programming Languages (M. L. Brodie, J. Mylopoulos, and J. W. Schmidt, eds.), Springer-Verlag, New York, New York, 1984, pp. 49-83.

F. P. Brooks, Jr., No silver bullet-Essence and accidents of software engineering, in Information Processing 86 (H. J. Kugler, ed.), Elsevier Science Publishers, New York, New York, 1986, pp. 1069-1076.

S. N. Zilles, Procedural Encapsulation: A Linguistic Protection Technique, ACM SIGPOiN Not. 8, 142-146 (1973).

C. A. R. Hoare, Proof of Correctness of Data Repre- sentation, Acta Informat. 1, 271-281 (1972).

A. Borgida, J. Mylopoulos, and H. K. T. Wong, Generalization/specialization as a basis for software specification, in On Conceptual Modelling: Perspec- tiaes from Artificial Intelligence, Databases, and Pro- gramming Languages (M. L. Brodie, J. Mylopoulos,


Antero Taivalsaari

J. W. Schmidt, eds.), Springer-Verlag, New York, New York, 1984, pp. 87-117.

82. R. Sethi, Programming Languages: Concepts and Con- structs, Addison-Wesley, Reading, Massachusetts, 1989.

83. C. M. Geschke and J. G. Mitchell, On the Problem of Uniform References to Data Structures (Proceed- ings of the 1975 International Conference on Reli- able Software), ACM SIGPLAN Not. 10, 31-43 (1975).

84. B. H. Liskov and J. Guttag, Abstraction and Specify- cation in Program Development, The MIT Press, Cam- bridge, Massachusetts, 1986.

85. M. L. Brodie and S. N.. Zilles, eds., Proceedings of the Workshop on Data Abstraction, Databases and Conceptual Modelling, ACM SIGPLAN Not. 16, 1 (1981).

86. B. H. Liskov, A. Snyder, R. Atkinson, and C. Schaf- fert, Abstraction Mechanisms in CLU, Commun. ACM 20, 564-576 (1977).

87. W. R. LaLonde and J. R. Pugh, Features of Fifth Generation Languages: A Panoramic View, Carleton University Computer Science Report SCS-TR-70, Ot- tawa, Canada, 1985.

88. H. L. Dershem and M. J. Jipping, Programming Lan- guages: Structures and Models, Wadsworth Publishing Company, Belmont, California, 1990.

89. W. R. Cook, Object-oriented programming versus abstract data types, in Foundations of Object-Oriented Languages (J. W. De Bakker, W. P. De Roever, and G. Rozenberg, eds.), Lecture Notes in Computer Science 489, Springer-Verlag, New York, New York, 1991, pp. 151-178.

90. A. Snyder, Encapsulation and Inheritance in Object- Oriented Programming Languages (OOPSLA ‘86 Conference Proceedings), ACM SIGPLAN Not. 21, 38-45 (1986).

91. A. Snyder, Inheritance and the development of encapsulated software components, in Research Direc- tions in Object-Oriented Programming (B. Shriver and P. Wegner, eds.), The MIT Press, Cambridge, Mas- sachusetts, 1987, pp. 165-188.

92. J. C. Reynolds, Gedanken-A Simple Typeless Lan- guage Based on the Principle of Completeness and the Reference Concept, Commun. ACM 13,308-319 (1970).

93. C. A. R. Hoare, Recursive Data Structures, Int. J. Comp. Info. Sci. 4, 105-132 (1975).

94. A. S. M. Sajeev and J. Olszewski, Manipulation of Data Structures without Pointers, Znfor. Proc. Lett. 26, 135-143 (1987).

95. W. Kim, E. Bertino, and J. F. Garza, Composite Objects Revisited (ACM SIGMOD ‘89 Conference Proceedings), ACM SIGMOD Rec. 18, 337-347 (1989).

96. J. Rumbaugh, Controlling Propagation of Operations Using Attributes on Relations (OOPSLA ‘88 Confer- ence Proceedings), ACM SIGPLAN Not. 23,285-296 (1988).

97. L. P. Deutsch, The past, present, and future of Smalltalk, in ECOOP ‘89 Conference Proceedings, The British Computer Society Workshop Series, Cambridge University Press, Cambridge, England, 1989, pp. 73-87.

98. J. Cohen, Garbage Collection of Linked Data Struc- tures, ACM Comp. Sum. 13, 341-367 (1981).

99. D. Ungar, Generation Scavenging: A Non-Disruptive High Performance Storage Reclamation Scheme (Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Soft- ware Engineering Environments), ACM SXGPLAN Not. 19, 157-167 (1984).

100. P. R. Wilson, Uniprocessor Garbage Collection Techniques, in 1992 International Workshop on Mem- ory Management, Springer-Verlag, in press.

101. A. H. Skarra and S. B. Zdonik, The Management of Changing Types in an Object-Oriented Database (OOPSLA ‘86 Conference Proceedings), ACM SZG- POlN Not. 21, 483-495 (1986).

102. S. B. Zdonik, Object-oriented type evolution, in Ad- vances in Database Programming Languages (F. Ban- chilhon and P. Buneman, eds.), ACM Press Fountier Series, Addison-Wesley, Reading, Massachusetts, 1990, pp. 277-288.

103. L. A. Cardelli, A semantics of multiple inheritance, in Semantics of Data Types (G. Kahn, D. B. Mac- Queen, and G. Plotkin, eds.), Lecture Notes in Com- puter Science 173, Springer-Verlag, New York, New York, 1984, pp. 51-67.

104. W. R. Cook, A Denotational Semantics of Inheri- tance, Ph.D. Thesis, Brown University, Providence, Rhode Island, 1989.

105. J. Zhu and D. Maier, Abstract Object in an Object- Oriented Data Model, Oregon Graduate Center Technical Report CS/E 87-015, 1987.

Documents

On the Notion of Object