On the Notion of Inheritance ANTERO TAIVALSAARI Nokia Research Center

One of the most intriguing—and at the same time most problematic—notions in object-oriented programming is inheritance. Inheritance is commonly regarded as the feature that distinguishes object-oriented programming from other modern programming paradigms, but researchers rarely agree on its meaning and usage. Yet inheritance is often hailed as a solution to many problems hampering software development, and many of the alleged benefits of object-oriented programming, such as improved conceptual modeling and reusability, are largely credited to it. This article aims at a comprehensive understanding of inheritance, examining its usage, surveying its varieties, and presenting a simple taxonomy of mechanisms that can be seen as underlying different inheritance models.

Categories and Subject Descriptors: D.1.5. [Programming Techniques]: Object- Oriented Programming; D.3.2. [Programming Languages]: Language Classifications object-oriented languages; D.3.3. [Programming Languages]: Language Constructs and Features General Terms: Languages Additional Key Words and Phrases: Delegation, incremental modification, inheritance, language constructs, object-oriented programming, programming languages

1. INTRODUCTION only currently well-developed and widely accepted area seems to be the A characteristic feature of object-ori- theory of inheritance in terms of denota- ented programming is inheritance. In- tional semantics [Cook 1989a; Cook and heritance is often regarded as the fea- Palsberg 1989; Reddy 1988]. ture that distinguishes object-oriented Despite the fact that much effort has programming from other modern pro- been targeted on research into inheri- gramming paradigms, and many of the tance in the past years, it seems that alleged benefits of object-oriented pro- inheritance is still often inadequately gramming, such as improved conceptual understood. Many studies of inheritance modeling and reusability, are largely concentrate only on one specific view- accredited to it. Despite its central role point, such as type theory or conceptual in current object-oriented systems, in- modeling, and mostly ignore the other heritance is still quite a controversial possible viewpoints. Depending on the mechanism, and researchers tend to dis- viewpoint, inheritance is regarded ei- agree on its meaning and usage. The ther as a structuring or modeling mech-

Author’s address: Nokia Research Center, P.O. Box 45, 00211 Helsinki; Finland; email: antero. [email protected]. Permission to make digital/hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. © 1996 ACM 0360-0300/96/0900–0438 $03.50

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 439 anism for reasoning about programs, or currently used synonyms for inheri- a mechanism for code sharing and re- tance in object-oriented systems are use. It seems that a more general, com- subclassing, derivation (in Cϩϩ) and prehensive view of inheritance is still prefixing (in Simula and Beta); in some missing. The main motivation for this papers the term subtyping is also used article was the desire to reach a more in the same meaning [Halbert and thorough understanding of inheritance O’Brien 1987], although more commonly from different viewpoints. that term is reserved for another pur- This article provides a comprehensive pose, as will be discussed in Section introduction to inheritance, starting 2.2.2. from its history and conceptual back- The basic idea of inheritance is sim- ground, examining its intended and ac- ple. Inheritance allows new object defi- tual usage, and discussing its essence in nitions to be based upon existing ones; light of the current knowledge. Further- when a new kind of an object class is to more, the varieties of inheritance are be defined, only those properties that analyzed, and a simple taxonomy of in- differ from the properties of the speci- heritance mechanisms is presented. fied existing classes need to be declared This article is a continuation to an ear- explicitly, while the other properties are lier article on object-oriented program- automatically extracted from the exist- ming [Taivalsaari 1993a], and part of a ing classes and included in the new larger study of inheritance, published class. Thus, inheritance is a facility for as the author’s doctoral thesis [Taival- differential,orincremental program de- saari 1993c]. velopment. Formally, inheritance can be characterized as follows [Bracha and 2. INHERITANCE Cook 1990; Cook 1989a; Wegner and Zdonik 1988]: If I have seen a little farther than others, it is because I have stood on the shoulders of giants. R ϭ P  ⌬R.

—ISAAC NEWTON In this maxim, R denotes a newly 2.1 Definitions defined object or class, P denotes the properties inherited from an existing In general, to inherit is to receive prop- object or class, ⌬R denotes the incre- erties or characteristics of another, nor- mentally added new properties that dif- mally as a result of some special rela- ferentiate R from P (the delta part), and tionship between the giver and the Q denotes an operation to somehow receiver [Danforth and Tomlinson combine ⌬R with the properties of P.As 1988]. This broad definition of inheri- a result of this combination, R will con- tance comes from the usage of the term tain all the properties of P, except that in the real world, and at the first con- the incremental modification part ⌬R sideration it seems to have very little to may introduce properties that overlap do with computers. Nevertheless, in the with those of P so as to redefine or context of programming, inheritance defeat (cancel) certain properties of P; was introduced as early as in the end of thus, R may not always be fully compat- the 1960s as a central feature of the ible with P. Compatibility issues will be programming language Simula [Dahl et discussed in Section 2.2.2. al. 1968]. However, Simula’s inheri- There are certain terms and notions tance mechanism was originally known pertaining to inheritance that will be by a different name, concatenation used throughout the article. For in- [Dahl et al. 1972, pp. 202–204; Nygaard stance, in the maxim above, P is known and Dahl 1978], and the intuitively as R’s parent or immediate ancestor;in more appealing term inheritance was class-based systems the corresponding invented some years later. Well-known term is superclass. Similarly, R is P’s

ACM Computing Surveys, Vol. 28, No. 3, September 1996 440 • Antero Taivalsaari

Figure 1. A simple example of inheritance. child, immediate descendant,orin dow and adds a new variable called title class-based systems its subclass. Inher- plus a method that redefines frame itance relationships are transitive, so drawing. The actual implementation of that a parent or superclass may be a the methods is elided. child or subclass of another object or In its basic form, inheritance can be class. This implies that in addition to characterized formally as record combi- incrementally defined properties, an ob- nation [Bracha and Lindstrom 1992; ject will contain all the properties of its Cardelli 1984; Cook 1989a]. An object or parents, parents’ parents and so on. The a class that inherits the properties of terms ancestor and descendant are used another is viewed as a record which is in the obvious manner to denote the otherwise similar to its parent, but immediate and nonimmediate parents which has been extended with some ad- and children of a class. ditional properties. This record combi- Most modern object-oriented systems nation can take place in several differ- allow inheritance from several parents ent ways, however. For instance, in at the same time. Such inheritance is class-based object-oriented systems (see known as multiple inheritance,asop- Section 3.1) the properties of an object posed to single inheritance discussed are typically located physically in differ- above. As multiple inheritance offers ent places, and this tends to make the considerably more possibilities for in- analysis more complicated. Further- cremental modification than single in- more, other issues such as early binding heritance, a generally accepted view is and encapsulation also encumber the that a modern object-oriented language analysis of inheritance. In general, in- should support it, despite the fact that heritance is not an independent lan- multiple inheritance also introduces guage feature, but it usually operates in many conceptual and technical intrica- tight interaction with other language cies. Issues pertaining to multiple in- mechanisms. heritance will be discussed briefly in the following section. For different defini- 2.2 Conceptual View of Inheritance tions of inheritance, refer to Cardelli [1984]; Cook [1989a]; Wegner [1987]; To attain knowledge, add things every day; to Wegner and Zdonik [1988]. obtain wisdom, remove things every day. As an example of inheritance, con- —LAO-TZU, Tao Te Ching sider the following pseudocode defini- tion (Figure 1). In the example, two A programming language is a notation classes, Window and TitleWindow, are and, as such, serves to record and assist defined. Class Window defines one vari- the development of human thought in a able, frame, and two operations (meth- particular direction. For a notation to be ods) drawFrame and drawContents. effective, it must carry a mental load for Class TitleWindow inherits class Win- the user and must have, among other

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 441 properties, economy and the ability to at the basic conceptual modeling rela- subordinate detail [Marcotty and tionships in order to elucidate the role Ledgard 1991]. By economy it is meant of inheritance as a modeling mecha- that a wide range of programs can be nism. expressed using a relatively small vo- Generally speaking, conceptual mod- cabulary and simple grammatical rules. eling can be defined as the process of An important goal in achieving this is organizing our knowledge of an applica- the orthogonality of language con- tion domain into hierarchical rankings structs. In other words, the language or orderings of abstractions, in order to should provide no more than one way of obtain a better understanding of the expressing any action in the language, phenomena in concern. The principles and each construct should be backed up according to which this process takes by solid conceptual and practical rea- place are usually referred to as the ab- sons. straction principles, abstraction mecha- In order to motivate the use of inher- nisms or abstraction concepts [Borgida itance in modern programming lan- et al. 1984; Mattos 1988]. One of the guages, let us now examine the relation- often mentioned benefits of object-ori- ship of object-oriented programming ented programming is that unlike other and conceptual modeling. modern programming paradigms, it pro- 2.2.1 Object-Oriented Programming vides direct support for each of the most and Conceptual Modeling important abstraction principles: (1) classification/instantiation, (2) aggrega- This structure of concepts is formally called a tion/decomposition, (3) generalization/ hierarchy and since ancient times has been a specialization and (4) grouping/individ- basic structure for all Western knowledge. ualization. —ROBERT M. PIRSIG, Zen and the Art of Motorcycle Classification, which is usually con- Maintenance sidered the most important abstraction Q: What’s big and gray, has a trunk, and lives in principle, is grouping like things to- the trees? gether into classes or categories over which uniform conditions hold [Borgida A: An elephant. I lied about the trees. et al. 1984]. Ideally, classes should —R. J. BRACHMAN share at least one such characteristic Object-oriented programming origi- that the members of other classes do not nated from Simula, a programming lan- have. Classification is an intensional guage that was initially targeted for the abstraction principle that ought to be simulation of real-world phenomena. based ideally on such properties of sub- Simulation is a task that requires a stances that do not change in the course great deal of conceptual modeling skills, of time. The reverse operation of classi- and therefore right from the beginning fication is instantiation,orexemplifica- the developers of Simula emphasized tion [Knudsen and Madsen 1988]. In- the importance of a close correspon- stantiation produces instances, entities dence between the program and prob- which fulfill the intensional description lem domain. As noted in Madsen et al. of their class. Collectively the instances [1990], the primary motivation leading of a class form the extension of that to the introduction of the class concept class. Most object-oriented languages in Simula, for example, was to model provide support for classification and the concepts in the application domain. instantiation by allowing the construc- Similarly, the inheritance mechanism tion of classes and instances. In proto- was initially introduced to represent type-based object-oriented systems (Sec- certain kinds of modeling relationships, tion 3.1) there are no classes, but the namely conceptual specialization [Mad- effect of instantiation can be simulated sen et al. 1990]. Let us now take a look by copying concrete objects. For a more

ACM Computing Surveys, Vol. 28, No. 3, September 1996 442 • Antero Taivalsaari extensive discussion on the notions of classes [Mattos 1988]. In particular, intension and extension, refer to Sowa specialization—allowing new concepts [1984, pp. 10–11]. to be derived from less specific classes— The second main abstraction principle seems intuitively as the natural high- is aggregation. By aggregation we refer level counterpart of inheritance, and to the principle of treating collections of therefore it has traditionally been as- concepts as single higher-level concepts: sumed that inheritance and specializa- aggregates [Borgida 1984; Smith and tion are simply different views of the Smith 1977a]. Aggregation describes same thing. Although at the first glance things in terms of parts and wholes. A this correspondence seems natural and part is a part by virtue of being included aesthetically pleasant, recently it has in a larger whole. A part can also be- been observed that the relationship be- come a whole in itself, which can then tween inheritance and conceptual spe- be split into further parts. Therefore, cialization can be confusing. This issue aggregation hierarchies are sometimes will be discussed in more detail in the also referred to as part-whole hierar- next section. chies. The reverse operation of aggrega- The fourth, perhaps the least obvious tion is decomposition, which yields the main abstraction principle is grouping, individual components of an aggregate. also known as association, partitioning Object-oriented languages typically sup- or cover aggregation [Brodie 1983; Mat- port aggregation/decomposition by al- tos 1988]. Frequently in conceptual lowing the use of objects as variables in modeling it becomes necessary to group other objects. Variables can be used to objects together not because they have hold other objects in order to construct the same properties (classification), but more complex part-whole hierarchies. because it is important to describe prop- In some papers the term composition is erties of a group of objects as a whole used as a synonym for aggregation. [Loomis et al. 1987; Mattos 1988]. The third major abstraction principle, Grouping addresses this need by allow- generalization, refers to the construc- ing the representation of possibly non- tion of concepts that cover a number of more special concepts sharing some sim- homogeneous collections of things re- ilarities [Knudsen and Madsen 1988; lated by their extensional rather than Smith and Smith 1977b]. On the basis by their intensional properties. Being of one or more given classes, generaliza- based on extensional properties, group- tion produces the description of a more ing bears some resemblance to the set general class that captures the common- theory of mathematics [Mattos 1988]. alities but suppresses some of the de- Object-oriented programming supports tailed differences in descriptions of the grouping by allowing the definition of given classes [Borgida et al. 1984]. The arbitrary collection classes such as lists, converse operation of generalization is sets, bags and dictionaries. The opposite of grouping is individualization, which specialization. A concept Cs can be re- garded as a specialization of another yields individual members of a collec- concept C if all phenomena belonging to tion; the term individualization is, how- the extension of the specialized concept ever, not very well-established. Cs also belong to the extension of C The abstraction principles have been [Pedersen 1989]. This implies that C illustrated in Figure 2, which gives an and Cs are otherwise similar, but Cs example of each principle applied to the may also possess some additional, more same application domain, namely Car. specific properties. Generalization and Furthermore, the list below summarizes specialization complement classification the main characteristics of each princi- in that they allow classes to be de- ple (adapted from Smith and Smith scribed naturally in terms of other [1980]).

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 443

Figure 2. Abstraction principles.

—Classification suppresses details of 2.2.2 Inheritance, Subtyping and Spe- instances and emphasizes properties cialization of a class as a whole. —Generalization suppresses the differ- The differentiae of genera which are different and ences between categories and empha- not subordinate one to the other are themselves sizes common properties. different in kind. For example, animal and knowl- —Aggregation suppresses details of edge: footed, winged, aquatic, two-footed, are dif- components and emphasizes details of ferentiae of animal, but none of these is a differ- the relationship as a whole. entia of knowledge; one sort of knowledge does not —Grouping suppresses details of a differ from another by being two-footed. group of objects and emphasizes the —ARISTOTLE, Categories §3 grouping of those objects together. The classical view of inheritance in ob- For further information on abstraction ject-oriented programming is that it is a principles, the reader is referred to hierarchical structuring mechanism in- Borgida [1984]; Knudsen [1988]; Loomis tended for conceptual specialization. In- et al. [1987]; Madsen and Møller-Ped- deed, language constructs for support- ersen [1988] and Mattos [1988]. ing generalization/specialization are

ACM Computing Surveys, Vol. 28, No. 3, September 1996 444 • Antero Taivalsaari often mentioned as the main character- between classes and their subclasses. istic of a programming language sup- The fourth level, behavior compatibility porting object-orientation [Madsen and assumes full behavioral compatibility Møller-Pedersen 1988]. Correspond- between classes and their subclasses. ingly, object-oriented programming has This implies that subclasses may not sometimes been characterized as “pro- change the behavior of their super- gramming with taxonomically organized classes in any radical way. The first data” [Cardelli 1984]. three forms of compatibility, being Recently it has however been ob- based on mere syntactic aspects of class served that the correspondence between definitions, are relatively easy to guar- inheritance and specialization is actu- antee, and inheritance mechanisms ally much more intricate than has pre- based on them are generally referred to viously been assumed [America 1987; as nonstrict inheritance [Wegner 1987; Wegner and Zdonik 1988; Zdonik 1986]. Wegner and Zdonik 1988]. Ensuring full Most of the problems in this respect behavior compatibility, however, turns arise from the fact that object-oriented out to be a much more difficult task. systems do not typically provide any The term strict inheritance is often used guarantees in that inheritance really is to refer to behaviorally compatible used for conceptual specialization. For forms of inheritance [Wegner 1987; instance, the redefined operations in a Wegner and Zdonik 1988]. subclass do not usually have to bear any While strict inheritance at the first semantic relationship to the replaced consideration seems to be the most de- operations in the superclass; the only sirable form of inheritance, there are semantic tie is that they share the same several other reasonable ways to use names [Zdonik 1986]. In general, if in- inheritance that necessitate nonstrict heritance is implemented in the conven- inheritance. These alternative uses of tional fashion, allowing unlimited addi- inheritance will be discussed in detail in tion, redefinition and cancellation of the next section. In fact, it has been properties in descendants, there is vir- argued that strict inheritance, i.e., the tually nothing to ensure that the con- use of inheritance for conceptual spe- ceptual correspondence between par- cialization, is of limited utility in the ents and their children really prevails. evolutionary development of complex Consequently, abstractions built using systems [Wegner 1987]. After all, strict inheritance rarely are true conceptual inheritance restricts the use of inheri- specializations of their parents. tance to the refinement of existing Some researchers have tried to guar- abstractions only, and prohibits the in- antee the conceptual correspondence be- cremental modification of those abstrac- tween parents and children by estab- tions in more creative ways. When us- lishing certain compatibility rules. For ing strict inheritance only, the addition instance, Wegner has identified four dif- of anything truly new to the system has ferent levels of compatibility between to be accomplished by constructing classes and subclasses [Wegner 1990; those abstractions from scratch. In gen- Wegner and Zdonik 1988]. The weakest eral, it seems that nonstrict inheritance of these, cancellation, allows the opera- can increase the expressive power of tions of the class to be freely redefined object-oriented systems. However, at and even cancelled (removed) in a sub- the same time it decreases structural class. The second level, name compati- clarity because so much less can be in- bility allows the operations to be rede- ferred about the properties of descen- fined, but requires the subclass to dants [Wegner 1987]. preserve the same set of names (i.e., no Another problematic issue in equat- properties may be removed). The third ing inheritance with specialization is level, signature compatibility requires multiple inheritance. An often cited con- full syntactic (interface) compatibility troversial example of multiple inheri-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 445 tance can be found in a book by Meyer One of the first researchers to empha- [1988]. In his book, Meyer defines a size this distinction was Brachman class Fixed_Stack by inheriting two pre- [1983] who investigated the role of is-a viously defined classes Stack and Array relationships in semantic networks. [Meyer 1988, pp. 241–242]. This is Brachman suggested that inheritance highly questionable because inheriting should be treated only as an implemen- these classes implies that Fixed_Stack, tational issue that bears no direct corre- in addition to being a specialization of spondence to conceptual modeling. Stack, would also be a specialization of Later papers to study the relationship Array. From the conceptual viewpoint, of inheritance and specialization in the this is incorrect since many operations context of object-oriented programming on arrays, such as the indexed element are America [1987; 1991], Cook et al. [1990], Palsberg and Schwatzbach access operations, are not generally ap- [1991], Porter [1992] and Raj and Levy plicable to stacks. The correct solution [1989]. A common argument in these in this case would be to inherit class papers is that in object-oriented sys- Stack only, and use class Array as a tems a clear distinction ought to be component. Similar abuses of multiple made between two important concepts: inheritance are surprisingly common in inheritance and subtyping. Inheritance the literature. In general, since multiple is a more low-level mechanism by which inheritance always results in a combi- objects or classes can share behavior nation of existing abstractions, it tends and data. Subtyping, on the other hand, to be difficult to regard it as a form of expresses conceptual specialization conceptual specialization. Rather, mul- [America 1991]. Following this dichot- tiple inheritance seems to have more in omy, inheritance is a mechanism that is common with aggregation. As aptly ex- suited but not necessarily limited to pressed by Alan Snyder in a panel dis- specialization (see Figure 3). In this cussion at OOPSLA’87: “multiple inher- context inheritance is often also re- itance is good but there is no good way ferred to more specifically as implemen- to do it.” For further information on tation inheritance, representation inher- using multiple inheritance refer to Du- itance or in class-based systems cournau and Habib [1987], Knudsen subclassing. Commonly used synonyms [1988] and Snyder [1991]. for subtyping are specification inheri- Based on the observations above it tance or interface inheritance [America should be obvious that equating inheri- 1987, 1991; Madsen et al. 1990]. Some tance with conceptual specialization papers also use the terms syntactic and poses several problems. Generally semantic inheritance to distinguish be- speaking, there seems to be a discrep- tween inheritance of implementation ancy between inheritance as a language and specification, respectively [Hart- mann et al. 1992]. mechanism and inheritance as a facility It is widely argued that using inheri- for conceptual modeling. These two tance for specialization is both theoreti- roles of inheritance can be characterized cally and practically valuable, while us- as follows [Korson and McGregor 1990]: ing it for mere implementation purposes is likely to cause difficulties and reflects (1) As part of the high-level program poor understanding of the purpose of design phase, inheritance serves as inheritance. Therefore, following the a means of modeling generalization/ Aristotlean tradition of dividing things specialization relationships. into essential and accidental, the use of (2) In the low-level implementation inheritance for specialization is often phase, inheritance supports the re- characterized as essential use of inheri- use of existing classes as the basis tance, whereas the other uses are con- for the definition of new classes. sidered more or less accidental or inci-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 446 • Antero Taivalsaari

Figure 3. Inheritance versus subtyping (traditional view).

dental [Sakkinen 1989]. However, as tion between inheritance and subtyping already mentioned above and as will be is the extra complexity that it places on discussed further in next section, there the implementation and use of lan- are other uses of inheritance beyond guages supporting such separation. specialization that can be considered Furthermore, it has been argued that well-justified and thus essential, too. not even this distinction is enough if Although the reasons for distinguish- one wants to be specific about the or- ing between inheritance and subtyping thogonality of language constructs. Sim- are widely recognized and accepted, so ilarly as there exists a distinction be- far this distinction has been incorpo- tween inheritance and subtyping, there rated only in a few programming lan- is a significant difference between sub- guages. Some languages making the typing and specialization. LaLonde distinction are POOL-I [America 1991] [1989] and LaLonde and Pugh [1991] and Typed Smalltalk [Graver and John- have proposed the following definitions son 1990; Johnson 1986]. In these lan- for the three concepts: guages subtyping serves as a higher- level relation between types, whereas —Subclassing is an implementation inheritance operates at the level of mechanism for sharing code and rep- classes. In most other (strongly-typed) resentation. object-oriented languages—including —Subtyping is a substitutability rela- Cϩϩ, Eiffel, Trellis/Owl [Schaffert et al. tionship: an instance of a subtype can 1986] and Simula—types are, however, stand in for an instance of its super- equated with classes, and inheritance type. is basically restricted to satisfy the —Is-a is a conceptual specialization re- requirements of subtyping [Cook et al. lationship: it describes one kind of 1990]. As observed in several papers object as a special kind of another. [Cook 1989b; Palsberg and Schwartzbach 1991], this can lead to problems in type Subclassing, subtyping, and special- checking. These type checking issues are, ization are all important for different however, beyond the scope of this article. reasons. Subclassing supports reusabil- A drawback of the suggested separa- ity for the class library implementor:

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 447

Figure 4. Subclassing, subtyping, and specialization. new kinds of classes can be defined by 2.2.3 Use of Inheritance in Practice leveraging off existing ones. Subtyping supports reusability for the class library Like the ski resort full of girls hunting for hus- user: to get maximum reusability, we bands and husbands hunting for girls the situa- need to know which classes can be sub- tion is not as symmetrical as it might seem. stituted with which other classes. Spe- —ALAN MACKAY cialization (is-a) relationships, in turn, Inheritance is a language mechanism are important for understanding the that allows new object definitions to be logical relationships between the con- based on existing ones. A new class inher- cepts; in this sense, specialization is its the properties of its parents, and may important for the class library designer. introduce new properties that extend, Figure 4 illustrates the differences be- modify or defeat its inherited properties. tween subclassing, subtyping, and spe- In general, most object-oriented lan- cialization [LaLonde and Pugh 1991]. guages allow the inherited properties to Each of the concepts in Figure 4 can be be reimplemented, renamed, removed, refined further. For instance, as observed duplicated, have their visibility changed, by Brachman [1983; 1985], there are sev- or undergo almost any other kind of eral kinds of is-a relationships. Varieties transformation as they are mapped from of subtyping have been examined by Weg- parents to descendants. Therefore, it is ner [1987], who distinguishes the follow- apparent that inheritance can be used for ing “subtypes” of subtyping: purposes that go beyond specialization. In —Subset subtyping. Int[1..10] is a sub- fact, the use of inheritance for conceptual set subtype of Int. specialization seems to be an ideal that is —Isomorphic copy subtyping. Int is an rarely realized. Most commercially avail- isomorphic copy subtype of Real. able class libraries, such as the standard classes of Smalltalk-80 or commercial —Object-oriented subtyping. Student is C class libraries, are permeated with an object-oriented subtype of Person. ϩϩ examples of using inheritance in other The varieties of inheritance and sub- ways. This section examines those uses of classing will be examined in the follow- inheritance that are common in real ob- ing subsections. ject-oriented systems, but which do not

ACM Computing Surveys, Vol. 28, No. 3, September 1996 448 • Antero Taivalsaari obey the semantic requirements of con- talk-80 [Goldberg and Robson 1989, pp. ceptual specialization. 144–169; Graver and Johnson 1990; La- Londe 1989; LaLonde et al. 1986; Weg- Inheritance for implementation refers ner 1990]. The Collection class hierar- to situations in which inheritance is chy consists of more than 20 classes used not because the abstractions to be that represent various kinds of con- inherited are ideal from the conceptual tainer objects such as Sets, Bags (sets point of view, but simply because they that allow duplicate elements), Dictio- happen to contain appropriate proper- naries (mappings from keys to values), ties for the new abstraction that is un- and Strings. Many of these classes have der construction. In implementation in- heritance, theoretical and conceptual been made subclasses of others simply issues such as behavior compatibility because the superclass happens to con- are ignored, and pragmatic reasons veniently provide the right functional- such as potential savings in coding ef- ity. For example, class Dictionary im- fort, storage space or execution speed plements a keyed lookup table as a hash are emphasized instead. As obvious, us- table of ͗key, value͘ pairs. The hash ing inheritance for mere implementa- table implementation is inherited from tion reasons is often questionable, and class Set (which in turn is a subclass of it has been criticized in the literature Collection), but applications using Sets [America 1987; Sakkinen 1989]. Some of would behave quite differently if given the most apparent variations of imple- Dictionaries instead. In other words, mentation inheritance are (adapted class Dictionary is behaviorally incom- from Rumbaugh et al. [1991, p. 64]): patible with its superclass. Besides con- venience, the Collection class hierarchy —cancellation, provides examples of cancellations and —optimization, and optimizations as well. For instance, —convenience. since Dictionary elements can only be removed by their key values, class Dic- In cancellation, the descendant re- tionary overrides the remove:ifAbsent stricts the inherited behavior by explic- method inherited from class Set with an itly making certain inherited properties error message method. Similarly, the unavailable, or by tightening the pa- iteration method do: is redefined in al- rameter type requirements. Cancella- most every collection class to optimize it tions are common in the Smalltalk-80 for each particular kind of abstraction. collection class hierarchy that will be Despite its idiosyncrasies, the Collec- discussed below. In optimization, the tion class hierarchy of Smalltalk does descendant takes advantage of some have its advantages. Generally it seems specific implementation information to that implementing the same functional- improve the code for its operations. For ity in a conceptually more elegant fash- example, a superclass Set could have an ion would necessitate a more complex operation to find the maximum element and more memory-consuming class hier- implemented as a sequential search; the archy. Cook has argued to the contrary, subclass SortedSet could provide a more however, and has presented an alterna- efficient implementation for the same tive Collection class hierarchy based on operation since the elements are al- the conceptual relationships of the ready sorted. In implementation inheri- classes [Cook 1992]. tance for convenience, the new class is made a subclass of the existing class Inheritance for combination refers to simply because the existing class seems situations in which inheritance is used to provide what is desired. for combining existing abstractions with The archetypical example of the use multiple inheritance [Halbert and of implementation inheritance is the O’Brien 1987]. As illustrated by the Collection class hierarchy of Small- Fixed_Stack example discussed in Sec-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 449 tion 2.2.2, such use of inheritance is in an object-oriented language without error-prone, and in many cases it would a module mechanism, the only viable be appropriate to use single inheritance way is to place those functions in a and aggregation instead. Nevertheless, separate class. This library class can two subforms of combination inheri- then be used in two different ways. The tance can be identified. First, multiple first possibility is to “instantiate” the inheritance is often used for combining library, which has the negative conse- abstractions of equal importance. The quence that the functions will have to classical example of such use of multiple be accessed indirectly via an interven- inheritance is to inherit two classes, ing variable. The second way is to use Teacher and Student, to form a class inheritance to simulate the import TeachingAssistant [Halbert and O’Brien mechanism of many abstract data type 1987; Sciore 1989]. In practice the com- (ADT) languages such as Modula-2 bination of conceptually equal abstrac- [Wirth 1985]. Using the library as a tions using multiple inheritance can be superclass, the functions in the library quite laborious, however, because such will be included in the scope of the abstractions tend to contain a large subclass and can thus be referred to number of overlapping properties that directly without extra effort. This is have to be dealt with in the subclass practical, but is yet another example of [Chambers et al. 1991]; sometimes this using inheritance for other reasons than may necessitate considerable modifica- conceptual specialization. tions. In many cases such situations Other uses of inheritance. In addi- could also be expressed more naturally tion to the above-mentioned uses of in- using roles [Pernici 1990]. For instance, heritance, some researchers have iden- from the conceptual viewpoint, Teacher tified several rarer forms of inheritance. and Student are not really proper sub- One such example is inheritance for classes of Person, but they should generalization that can be seen as the rather be seen as different roles that opposite of inheritance for specializa- persons are capable of playing at differ- tion [Halbert and O’Brien 1987; Ped- ent times. The second form of inheri- ersen 1989]. Like specialization, inheri- tance for combination is mixin-based in- tance for generalization is based on heritance,ormixin inheritance [Bracha conceptual reasons, but the actual di- and Cook 1990; Hendler 1986], which rection of conceptual relationships has has recently received considerable at- been reversed. In other words, rather tention. Mixin inheritance originated than specializing the behavior of its from the programming languages Fla- parent, a descendant is designed as a vors [Moon 1986] and Oaklisp [Lang generalization of its parent. Inheritance and Pearlmutter 1986], and has subse- for generalization has been investigated quently been utilized in the Common in detail by Pedersen [1989], who con- Lisp Object System (CLOS) [DeMichiel siders such use of inheritance valuable and Gabriel 1987; Keene 1989]. Mixin when changes to the existing classifica- inheritance will be discussed in more tion hierarchy are needed and when detail later in Section 3.7. those changes should be accomplished Inheritance for inclusion. One alter- incrementally rather than by modifying native use of inheritance is also inheri- the existing inheritance hierarchy. An- tance for inclusion. Many class-based other advantage of generalization is object-oriented languages (e.g., Small- that in some situations it may be easier talk) do not provide a separate module to implement abstractions as generali- mechanism, and thus classes are some- zations of more special concepts than times needed for simulating modules or vice versa [Halbert and O’Brien 1987; function libraries. For instance, to cre- Pedersen 1989]. For example, if a sys- ate a library of trigonometric functions tem already incorporates a deque ab-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 450 • Antero Taivalsaari straction, then the implementation of useful, it will have to be changed. stack by generalization is easier than Therefore, one of the most important by constructing it from more general qualities of software is malleability,or abstractions [Snyder 1986a]. modifiability; the easier the software In conclusion, there is no single answer system is to change, the more likely it is as to what constitutes proper use of in- that it will fulfill the requirements it heritance. Although conceptual special- was built to satisfy, and the more easily ization was originally regarded as the it will be able to keep up with the evolv- only legitimate reason for using inheri- ing needs of the users. Traditional pro- tance, in practice inheritance is com- gramming methodologies do not take monly used for other quite reasonable this evolutionary nature of software purposes. Consequently, a major theme into account very well. The principles of in the object-oriented programming re- abstract data type (ADT) programming, search in the past years has been the such as locality of information, modu- clarification of the role of inheritance. larity and representation independence Despite these efforts, researchers still [Liskov 1987], provide some help in this have differing opinions on inheritance, respect, but are unable to solve some of and a lot of work in this area remains to the most central issues. be done. One of the main problems plaguing software development is that program 2.3 The Essence of Inheritance modification, in the traditional fashion, is a process of destructive or radical On the basis of the preceding discussion change [Cook 1989a; Cook and Palsberg it appears that the analogy between in- 1989]. In many situations, even small heritance and conceptual specialization modifications to some parts of the sys- is a lot weaker than has often been tem will have widespread effects on the claimed. In order to reach a better un- other parts. The larger the software sys- derstanding of what the essence of in- tem is, the greater is the likelihood of heritance in object-oriented program- undesired, inadvertent side-effects. Yet ming really is, let us now set the many of the changes in software sys- conceptual modeling viewpoint aside for tems do not really necessitate destruc- a while, and approach the issue from a tive modification. If the modifications, more pragmatic viewpoint. The section replacements, or removals of existing starts by recognizing certain inherent parts of the program were explicitly problems in traditional programming avoided, and an incremental program- methodologies and by showing how in- ming style were adopted, these unfore- heritance can address these problems. A seen effects could be avoided. more theoretical discussion of the es- To properly understand the problems sence of inheritance will then follow. with destructive modification, let us 2.3.1 Inheritance as an Incremental consider an example in which we are Modification Mechanism building a simple graphical windowing system. In Figure 5, we define a class Ours is a world of things—but of changing things Window whose instances are assumed not quiescent ones. to be windows on the screen. To avoid extra verbosity and complexity, only a —MARIO BUNGE, The Furniture of the World small subset of the variables and opera- There are six kinds of change: generation, de- tions needed in implementing a real struction, increase, diminution, alteration, change window system have been included. It is of place. assumed that methods drawFrame and drawContents display the frame and the —ARISTOTLE, Categories §14 contents of a window on the screen at A well-known fact in software devel- the location specified by the variable opment is that if a piece of software is rect. Method refresh invokes both these

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 451

Figure 5. Class Window. methods in order to update both the the changes to the existing components frame and the contents. Since the exam- are relatively small in proportion to the ple will be used to illustrate further overall size of the component. Further- aspects of inheritance in the end of this more, textual copying loses the relation- section, references to methods draw- ship between the original and copied Frame and drawContents have been de- component, and this is likely to cause noted using a special pseudovariable maintenance problems later on. In gen- self. At this point these self-references eral, there are two arguments against can simply be ignored. tampering with existing source code Suppose we would later like to modify [Krueger 1992]. our window system to support windows that are capable of displaying a title —Editing source code forces the soft- (name) on their frame. In conventional ware developer to work at a low level ADT systems this can be achieved in of abstraction. The effort required to two basic ways. The first way is to edit understand and modify the low-level the source code of the existing class details of a component offsets a signif- Window to support both plain windows icant amount of the effort saved in and windows with a title. This could be reusing the component. accomplished by adding a new variable —Editing source code may invalidate to hold the title of the window, and the correctness of the original compo- another variable to store information of nent. This eliminates the ability to whether the current window is a plain amortize validation and verification one or one with a title. Additionally, a costs over the life of a reusable com- case statement should be added to ponent. method drawFrame to determine whether or not the title should be Inheritance addresses the above men- printed on the frame. tioned problems by promoting incre- The second way to achieve the same mental definition. By adding new prop- effect is to copy the source code of the erties, a new class can extend, modify existing Window class and edit the copy and defeat the properties inherited from to form a completely new TitleWindow its parents, but the original class still class—this approach can be called the remains the same. However, note that “copy-and-modify” scheme. Neither of the avoidance of destructive changes it- these approaches is really satisfactory. self is not enough. So as to avoid unnec- In a large system direct modification of essary redefinitions, some extra linguis- an existing component is likely to cause tic support is needed. Consider the inconsistencies with the other compo- definition in Figure 6. nents that happen to refer to the prop- The class definition in Figure 6 is an erties of the modified component. The attempt to define a new class TitleWin- copy-and-modify scheme, on the other dow as an extension of the previously hand, is uneconomical, because usually defined class Window. Since class Win-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 452 • Antero Taivalsaari

Figure 6. Class TitleWindow. dow implements the basic functionality In the window system example above, of windows, it seems apparent that in for instance, the use of late-bound self- order to create windows with a title on reference causes the behavior of opera- their frame, the only thing that needs to tion refresh to vary dynamically depend- be redefined is the previously defined ing on which kind of a window it is operation drawFrame. However, a prob- currently acting upon, thereby ensuring lem with this approach is that after the that the correct drawFrame operation redefinition of drawFrame, all those op- can be invoked. erations in superclass Window that hap- What do we learn from all this? First, pen to refer to the original operation it is apparent that many modifications drawFrame, such as refresh, are invalid. needed in software systems could be When applied to instances of TitleWin- performed incrementally, yet conven- dow, method refresh will still invoke the tional systems enforce these modifica- original method drawFrame of class tions to be carried out in a destructive Window, thus producing windows with- manner. Second, late binding is a pre- out a title on their frame. requisite for implementing a system In general, it is common for class def- that allows true incremental modifica- initions to contain a large number of tion. Without late binding, there is no operations that refer to the other opera- assurance that newly defined compo- tions in the same definition. These in- nents will work correctly when inher- terdependencies between classes make ited operations are applied to them. In incremental modification problematic; if general, inheritance can be defined as one operation is redefined in a descen- follows (adapted from Cook [1989a] and dant, all the other operations referring Cook and Palsberg [1989]): to that operation will also have to be redefined. This is inconvenient and Inheritance is an incremental modifica- against the idea of incremental modifi- tion mechanism in the presence of a cation. For this reason, an additional late-bound self-reference. language mechanism, late binding,is A detailed description of the semantics needed. Late binding allows references of late binding and self-reference will be to the properties of objects to be post- given in the next section. poned until the program is actually run, thus making operations polymorphic, 2.3.2 Late Binding and Self-Reference i.e., able to take on different meanings To thine own self be true. at different times. By virtue of late —WILLIAM SHAKESPEARE, Hamlet binding, references to other properties from within an operation do not have to Inheritance is an incremental modifica- be statically fixed, but may invoke dif- tion mechanism. By virtue of inheri- ferent properties depending on the con- tance, a new object class can extend text from which the operation is actu- itself by internalizing properties of an- ally invoked. This dynamic context is cestors as though they were its own determined by self-reference, a pseudo- [Wegner 1987]. Late binding, as implied variable that denotes the object whose above, allows this internalization to be operation is currently being executed. performed in a manner that minimizes

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 453

Figure 7. Semantics of message passing with late binding. the need for physical code duplication, tance DAGs if so desired. The mapping by letting the same operations invoke between classes and their instances different properties depending on the may not always be totally one-to-one, context from which these operations are however, because repeated inheritance invoked, thereby promoting sharing of (e.g., a class having two superclasses code. This section takes a more theoret- that have a common superclass; also ical look at how incremental modifica- known as fork-join inheritance [Sakki- tion is actually achieved, and gives a nen 1989], or diamond inheritance general description of the semantics of [Bracha 1992, pp. 24–26]) may cause late-bound message sending. Since we some instance variables to be dupli- are not yet focusing on any particular cated. Bear in mind that an essential model of inheritance, the description restriction on all inheritance hierar- will be kept independent of implementa- chies is that they may not contain cy- tion aspects. cles. This restriction is obvious as it Theoretically, inheritance can be would be nonsensical for abstractions to characterized as the operation that de- inherit their own properties. rives new abstractions from previously If objects are viewed as directed acy- defined ones, denoted formally R ϭ P Q clic graphs, the semantics of inheritance ⌬R, or in the case of multiple inheri- can be described quite easily and inde- tance: R ϭ P1 Q P2 Q ... Q Pn Q ⌬R. pendently of any particular model of When applied transitively, the opera- inheritance. Whenever a late-bound tion results in abstraction hierarchies message is sent to an object, the follow- that take the form of tree (in the case of ing kind of an algorithm will take con- single inheritance), or more generally: trol. The algorithm is illustrated in Fig- directed acyclic graph (DAG; see Amer- ure 7 (adapted from Cook [1989a] and ica [1987] and Knudsen [1988]). Each Cook and Palsberg [1989]). Parts of the node in an inheritance DAG represents figure will be discussed also in the next a collection of properties that has been subsection. incrementally added on top of the inher- ited properties at some particular level, (1) First, self-reference is set to refer to corresponding to a delta part in some the receiver of the message. Previ- “R ϭ P Q ⌬R” declaration. ous value of self-reference is saved Note that although in object-oriented so that it can be restored later. In systems inheritance is typically possible Figure 7, this phase is called SEND. only between classes, there is usually (2) The given message selector is then an isomorphic correspondence between matched against the properties of classes and their instances, so that in- the receiver by traversing its inher- stances can also be viewed as inheri- itance DAG node by node. The ac-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 454 • Antero Taivalsaari

tual traversal order depends on the maintained and cannot be modified by form of inheritance being used (Sec- the programmer. tion 3.3). In Figure 7, this phase is In different languages different called LOOKUP. names for the self-reference are used. (3) If a matching property is found in Smalltalk and its derivatives use self, some node, the matching property is whereas in Simula, Beta [Kristensen et invoked, e.g., using a normal proce- al. 1983; Madsen and Møller-Pedersen dure call mechanism. In Figure 7, 1989] and Cϩϩ the corresponding lan- this phase is termed CALL. After guage construct is known as this. Eiffel execution, the previous value of self- provides a pseudovariable current for reference is restored. the same purpose [Meyer 1988, p. 79 and 177]. In some object-oriented lan- (4) In case no matching property can be guages self-references are implicit. In found in the whole DAG, a binding Eiffel, for instance, current is usually error will be raised. In Figure 7, this elided, and thus late-bound operation phase is called ERROR. invocations look syntactically identical As a result of successful late binding, to ordinary procedure calls in conven- the matching operation of the object will tional programming languages. The be invoked. During the execution of the Cϩϩ programmer may explicitly decide operation, the self-reference will remain whether or not to use this in his mem- denoting the root of the current inheri- ber function calls. tance DAG, so that subsequent message 2.3.3 Accessing Overridden Proper- sends via the self-reference from within ties. Besides self, object-oriented lan- that operation can access the other guages typically provide other pseudo- properties of the object. By virtue of late variables that contribute to the binding, operations inherited from par- incremental definition of programs. The ents can invoke such properties that most common of these is super [Gold- were not necessarily even implemented berg and Robson 1989, pp. 63–66] that at the time when the parent was de- is used for accessing those inherited fined. properties that have been redefined in Note that in actual implementations subclasses. When an operation sends a of object-oriented languages, the above message via super, the lookup is started described algorithm is usually replaced from the immediate parent of the node with much more efficient strategies. possessing that operation. This is differ- Simple inline caching techniques ent from normal message lookup in [Deutsh and Schiffman 1984], for in- which the lookup is always started from stance, eliminate the need to perform the node denoted by the self-reference. the actual lookup in 95 percent of the When using super, the self-reference is situations. Various optimization tech- left untouched, so that subsequent mes- niques have been surveyed in Driesen et sages via self from the redefined opera- al. [1995]. tions will be able to access the more To the programmer, the self-reference recently defined properties. typically appears in the form of a spe- In order to illustrate the behavior of cial pseudovariable, self, that can be super, let us take the class TitleWindow used explicitly to inform the system defined in Section 2.3.1 into consider- that late binding via self-reference is ation again. In that example we rede- requested. At the language level, self is fined the operation drawFrame in order treated as a free variable whose textual to construct windows with a title on occurrences in a program are bound to a their frame. In such a situation it would particular object only at the time they apparently be a great help if we could are executed. By the term pseudovari- somehow utilize the previously defined able it is implied that self is system- drawFrame operation of superclass

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 455

Figure 8. Class TitleWindow using super-reference.

Window. However, since the purpose of [Meyer 1988, pp. 246–250]. Some lan- class TitleWindow is primarily to de- guages, such as Simula and Deltatalk scribe the title extension, it should [Borning and O’Shea 1987] do not pro- know as little as possible about the ac- vide any facilities for accessing rede- tual frame drawing process. In order to fined operations, and this may limit in- avoid code duplication, the new draw- cremental modification in many Frame operation for TitleWindow situations. In Self [Ungar and Smith should apparently first invoke the ear- 1987], the super-reference was origi- lier drawFrame operation, thus drawing nally called super, but later renamed as the plain border, then calculate the cor- resend [Chambers et al. 1991]. rect position for the title, and print the In general, late binding, self-reference title on the frame. This is exactly what and super-reference are salient ele- can be accomplished using the super- ments of all inheritance mechanisms. reference (see Figure 8). Without super, Late binding and self-reference allow the whole frame printing algorithm the programmer to perform “surgery” would have to be reimplemented in the which can change object behavior with- subclass. Thus, the super-reference is out physically reaching inside any ob- an invaluable tool for reducing the need ject. Super-reference supplements these for code reimplementation and contrib- facilities by allowing access to redefined uting to incremental modification. properties, thereby reducing the need Several variations of super-reference for code duplication. When used prop- exist. Whereas super is characteristic of erly, together these facilities allow the languages modeled after Smalltalk, in properties of objects to be reused with- CLOS the corresponding language con- out any textual copying or editing, struct is known as call-next-method which is a major advantage over other [Keene 1989, p. 233]. Unlike super, programming styles and techniques. In CLOS’s call-next-method does not re- this sense, inheritance is a truly novel quire any message selector as parame- and fundamental mechanism for con- ter, but uses the previous selector name structing programs [Cook 1989a]. by default. In this sense CLOS’s call- next-method is analogous to Beta’s inner 2.3.4 Inheritance as a Specificational construct [Kristensen et al. 1983], al- Structuring tool though otherwise Beta’s inheritance scheme is radically different (see Sec- Inside every large program there is a small pro- tion 3.3). Cϩϩ gives the programmer gram trying to get out. the ability to access redefined proper- —C.A.R. HOARE ties by using superclass names as qual- ifiers [Ellis and Stroustrup 1990, p. Incremental modification is not a pana- 390]. Eiffel does not provide any explicit cea. Not all modifications to programs super-reference, but allows the same ef- can be performed incrementally. Never- fect to be simulated by renaming the theless, many of the problems in con- inherited properties in the subclass ventional software development meth-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 456 • Antero Taivalsaari odologies can be alleviated considerably ogy [Madsen and Møller-Pedersen using incremental modification. One ad- 1989], and partial types [Halbert and ditional benefit of inheritance in this O’Brien 1987]. respect is that it enables the construc- Representative examples of abstract tion of partially,orincompletely imple- classes in object-oriented systems are mented abstractions. By partially imple- classes Object and Collection in Small- mented abstractions we refer to talk. Smalltalk’s class Object is an ab- abstractions whose definitions have stract superclass that defines the gen- purposely been left incomplete, and eral properties of all objects in the whose properties may thus refer to such Smalltalk system [Goldberg and Robson components or properties that have not 1989, pp. 94–103]. Instantiation of class even been implemented yet; late bind- Object would, however, make little ing is obviously needed for this. Ab- sense since Object exhibits no other be- stractions of this kind are sometimes havior than these general operations. extremely useful, because they can Similarly, class Collection defines the serve as specifications or contracts upon general message protocol for various which the concrete implementations can collection classes such as dictionaries, be based, thus facilitating the conver- sets, arrays and strings. Many opera- gence of analysis, design, and imple- tions in class Collection, such as the mentation. Such abstractions often have iteration method do:, have deliberately a communicative role, allowing the de- been left unimplemented, however, and signers to agree upon the interfaces of are to be added by the subclasses. the abstractions before the actual im- In systems utilizing mixin inheritance plementation efforts are started. In gen- (see Section 3.7), partial implementa- eral, these ideas are intimately related tions are used for another purpose. Mix- to Wirth’s notion of successive,orstep- ins are small, noninstantiatable por- wise refinement [Wirth 1971]. tions of behavior that are used solely for In class-based object-oriented sys- adding properties to other classes. tems, partial implementation is usually Mixin classes do not define any general supported in the form of abstract framework or serve as specifications of classes. An abstract class is a class that some larger abstraction hierarchy. specifies a message interface, but does Rather, they just describe reusable not fully implement it. Such a class is pieces of functionality that can be at- written with the expectation that its tached to other classes using multiple subclasses will add to its structure and inheritance. Therefore, as opposed to behavior, usually by completing the im- ordinary abstract superclasses, mixin plementation of its incomplete opera- classes are sometimes referred to as ab- tions. Since abstract classes are imple- stract subclasses [Bracha and Cook mented only partially, by convention no 1990]. instances are created from them. In In general, we can distinguish two fact, in some papers abstract classes are additional forms of inheritance: inheri- defined as classes which even cannot be tance from complete implementations instantiated; many systems, such as and inheritance from partial implemen- Smalltalk-80, do not guarantee this, tations [Halbert and O’Brien 1987]. however. Since abstract classes serve Both forms rely on performing modifica- only to provide inheritable functional- tions in an incremental fashion and are ity, they are often also referred to as thus subcategories of the more general abstract superclasses [Bracha 1990]. notion of incremental modification. In- Other frequently used synonyms are ba- heritance from complete implementa- sic classes in CLOS terminology [Keene tions allows the reuse and refinement of 1989, p. 224], deferred classes in Eiffel existing complete abstractions, while in- terminology [Meyer 1988, pp. 234–240], heritance from partial implementations abstract superpatterns in Beta terminol- serves as a specificational structuring

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 457 tool, enabling the successive refinement common constituents further. This sec- of programs from abstract specifications tion undertakes a detailed analysis of towards successively more concrete im- the variations of inheritance mecha- plementations. Some researchers have nisms in object-oriented programming argued that inheritance from complete systems, aiming at new insights as to implementations is harmful and should what the possible common constituents be avoided [Lieberherr et al. 1988; of different inheritance models are. At Lieberherr and Holland 1989]. the same time, some further concepts Note that in a way, abstract classes and notions will be introduced. Finally, have a dual role. On the one hand, they a simple taxonomy of the basic mecha- have a conceptual role, and serve as nisms and issues underlying the seem- specification or design tools in the above ingly divergent forms of inheritance will described manner, their presence being be presented. motivated by the conceptual analysis of the problem domain. On the other hand, 3.1 Class Inheritance Versus Prototype abstract classes also have a more prag- Inheritance matic role: to serve as hooks for improv- ing reusability. These two roles are not Class is a state of grace that few people have. necessarily coincident; in order to make —DOROTHY CULLMAN a class hierarchy as reusable as possi- ble, it is often essential to split the Prototype: the first or primary of anything; the problem domain into smaller classes original (thing or person) of which another is a (and have more abstract classes) than copy, imitation, representation, or derivation, or is would otherwise be necessary from the required to conform; a pattern, model, standard, conceptual viewpoint. This is because exemplar, archetype. the smallest unit of reuse in most ob- —Oxford English Dictionary VIII, p. 1512 ject-oriented systems is the class. Mixin inheritance discussed later in Section Object-oriented systems are usually 3.7 is a good example of the potential built around classes. Classes are de- discrepancy between reuse and model- scriptions of objects capable of serving ing. as templates or “cookie-cutters” from which instances, the actual objects de- 3. VARIATIONS OF INHERITANCE scribed by classes, can be created. This creation process is typically known as Understanding depends on expectations based on instantiation. In broad terms, a class familiarity with previous implementations. represents a generic concept, or a “reci- pe,” while an instance represents an —MARY SHAW individual. A class holds the similarities What we’ve got is freedom of choice. What we among a group of objects, dictating the want is freedom from choice. structure and behavior of its instances, whereas instances hold the local data —From a song by a new-wave band, Devo representing the state of the object. Object-oriented language design space Class-based systems are quite class- is not a dichotomy, and these lan- centric. To add a new kind of an object guages cannot be categorized into com- to the system, a class describing the pletely clear-cut, orthogonal subclasses. properties of that object type must be Rather, they seem to be more like a defined first. Similarly, inheritance can result of “mixin inheritance”: the same only take place between classes, basic themes and patterns are repeated whereas instances are completely “ster- over and over again in slightly different ile”, i.e., incapable of serving as parents. forms and variations. This similarity Therefore, the model is commonly re- between models is intriguing, and it ferred to as class inheritance [Stein et sparks the desire to explore the possible al. 1988; Wegner 1987, 1990].

ACM Computing Surveys, Vol. 28, No. 3, September 1996 458 • Antero Taivalsaari

An interesting alternative for tradi- they are at absorbing general abstract tional class inheritance is prototype in- principles first and later applying them heritance,orobject inheritance [Blas- in particular cases [Lieberman 1986]. chek 1994; Borning 1986; Dony et al. There are many variations of proto- 1992; Liebermann 1986; LaLonde et al. type-based systems [Dony et al. 1992; 1986; Stein et al. 1988; Stein 1987; Un- Taivalsaari 1993c]. Roughly speaking, gar and Smith 1987]. As opposed to prototype-based object-oriented lan- class-based systems, in prototype-based guages can be divided into two broad systems there are no classes. Rather, categories according to how incremental new object types are formed directly by modification is supported in them: dele- constructing concrete, full-fledged ob- gation-based and copying-based. In del- jects, which are referred to as prototypes egation-based languages, there is a spe- or exemplars. A prototype can be cial delegation mechanism that provides thought of as a standard example in- the incremental modification capability stance, which represents the default be- [Lieberman 1986]. In delegation-based havior for some concept. Prototype- languages, when an object receives a based systems provide no classes, and message it does not understand, the ob- therefore in these systems there is no ject will delegate the message to those notion of instantiation either. The effect objects that have been designated as its of instantiation, the ability to create “parents.” Parent objects will then try to multiple objects of similar kind, is carry out the message on the delegating achieved by cloning (copying) existing object’s behalf. During the delegation objects instead. In addition, objects in process, the self-reference will remain prototype-based systems are usually in- pointing to the original receiver, allow- dividually modifiable. By virtue of the ing late-bound properties in parents to individuality of objects, prototype-based operate in the context of the original systems support incremental modifica- receiver. Delegation will be discussed in tion at the level of individual objects, as more detail in the next section. The best opposed to class-based systems in which example of a delegation-based object- typically only groupwise (class-level) oriented language is Self [Ungar and modification is possible. Smith 1987], a Smalltalk-like language From the philosophical viewpoint the that has become the yardstick against distinction between class-based and which other prototype-based object-ori- prototype-based systems reflects the ented languages are measured. long-lasting philosophical dispute con- Borning [1986] has shown that a pro- cerning the representation of abstrac- totype-based language does not neces- tions. Plato viewed forms—stable, im- sarily have to support delegation in or- mutable descriptions of things—as der to be a full-fledged object-oriented having an existence more real than in- language. Borning demonstrated that stances of those abstractions in the real by utilizing cloning (copying) and the world [Plato 1981, Books 6 and 7]. Ob- possibility to dynamically add new prop- ject-oriented languages like Smalltalk erties to objects in the presence of the and Simula are Platonic in their explicit regular late-binding message sending use of classes to represent similarity mechanism, it is possible to capture the among collections of objects. Prototype- essence of inheritance—incremental based systems represent another way of modification—in a prototype-based lan- viewing the world, in which one chooses guage even without delegation. Unless not to categorize things, but rather to supplanted with some additional mech- exploit their alikeness. A typical argu- anisms and implementation techniques, ment in favor of the prototype-based this model has some problems, however. approach is that people seem to be a lot In particular, as a result of extensive better at dealing with specific examples use of copying, memory consumption first, then generalizing from them, than can be excessively high. Also, groupwise

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 459 modification of objects is more tedious using references. Concatenation, on the than in delegation-based systems due to other hand, achieves the same effect by absence of common parent objects or copying the interface of the parent into any explicit inheritance hierarchy. Ex- the interface of the descendant—as a amples of prototype-based object-ori- result of this, the descendant’s interface ented languages built along the lines of will be contiguous. As an example of Borning’s model are Omega [Blaschek delegation and concatenation, consider 1991] and Kevo [Taivalsaari 1993c]. the simple example below. Let us as- Prototype-based object-oriented lan- sume that we have the following kind of guages have been discussed in detail in object aPen defined in our system with a book by Blaschek [1994]. two variables x and y and a method called draw, defined using simple record 3.2 Delegation Versus Concatenation notation. Inheritance is acquisition of properties aPen:-[VAR x, VAR y, METHOD draw]; from past generations. More practically, Suppose that we now want to define inheritance is a relationship between another object aTurtle that inherits the objects that guarantees that a descen- properties of aPen and adds a new vari- dant has at least the properties that its able heading and a method forward.If parents have. By incrementally adding, we accomplish this using delegation, the redefining or defeating properties, the interface of the descendant will be as descendant can become differentiated follows: from its parents. At the level of object aTurtle:-[PARENT p :-aPen, VAR heading, interfaces this implies that the record METHOD forward]; representing the descendant must con- tain at least those identifiers that its On the other hand, using concatenation parents have. In addition, the descen- the interface of the resulting object will dant can introduce new identifiers that be contiguous, as illustrated below: are either distinct or overlapping.An aTurtle:-[VAR x, VAR y, METHOD draw, incrementally added identifier is said to VAR heading, METHOD forward]; be distinct if no other identifiers with the same name exist in the same inher- In both cases the basic result is the itance DAG. Otherwise, the identifier is same: the descendant will be able to overlapping. In general, from the view- respond to messages corresponding to point of interface management, inheri- the inherited identifiers in addition to tance is simply a combination operation the incrementally added ones. However, R ϭ P Q ⌬R on record structures P ϭ the way in which message sending is [...]and⌬Rϭ[. . .] with possibly over- handled in these approaches is differ- lapping identifiers (see Wegner and ent. In delegation, those messages that Zdonik [1988]). This combination opera- are not accepted by the most specialized tion must be able to relate the interface part of the object must be delegated (name space) of descendant R to the (forwarded) to parents. In concatena- interface of parent P. tion, the interface of every object is self- Within computer memory there are contained, and thus no forwarding is only two ways to express direct relation- needed. Since the term delegation im- ships between things: references or con- plies shared responsibility for the com- tiguity. Based on this observation, two pletion of a task, it would be misleading elementary strategies for implementing to use that term to denote also the inheritance can be distinguished: dele- latter form of inheritance. Delegation gation and concatenation. Delegation is and concatenation have been illustrated a form of inheritance that implements in Figure 9. interface combination by sharing the in- Note that the difference between del- terface of the parent—in other words, egation and concatenation is indepen-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 460 • Antero Taivalsaari

Figure 9. Delegation versus concatenation. dent of the question of whether the sys- is analogous to the delegation approach tem is based on classes or prototypes; adopted in prototype-based languages delegation and concatenation can such as Self. In both approaches unre- equally underlie both models. The main solved messages will always be for- difference is that in class-based systems warded to separate constructs; in Small- delegation or concatenation takes place talk this separate construct is a between classes, whereas in prototype- superclass, and in Self it is a parent based systems the same occurs between object. individual objects. In fact, although the In general, delegation and concatena- term concatenation is not widely used in tion are distinct strategies for imple- the current literature of object-oriented menting inheritance, both of which programming, there are good historical can equally underlie class-based and reasons for its use. The concept of pre- prototype-based systems. Simula and fixing in Simula [Dahl et al. 1968], its descendant Beta are examples of which later evolved into the modern languages which implement class inher- concept of inheritance, was originally itance by concatenation. Smalltalk, on defined in terms of textual concatena- the other hand, implements class inher- tion of program blocks [Cook and Pals- itance by delegation. Self is the best berg 1989] (see Dahl et al. [1972, pp. example of a language that implements 202–204, Nygaard and Dahl 1987]). prototype inheritance by delegation. The Even in the current implementations of copying-based approach discussed in Simula and its descendant Beta [Kris- Section 3.1 represents prototype inheri- tensen et al. 1983] the interfaces (to be tance by concatenation. Thus, although more specific: the virtual operation it has sometimes been claimed that del- search tables) of classes and their sub- egation is a mechanism that can be classes are self-contained and indepen- thought of as underlying all inheritance dent of each other [Madsen and Møller- mechanisms [Stein 1987], this is not Pedersen 1988; Magnusson 1991]. On really the case. One of the few papers in the other hand, as shown by Stein which a similar distinction between dif- [1987], the way that inheritance be- ferent kinds of object-oriented systems tween classes is achieved in Smalltalk has been made is, Snyder [1991],

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 461

Table 1. Delegation versus concatenation.

wherein Snyder distinguishes mono- sharing makes it easier to optimize the lithic objects and multiobjects. Snyder’s method lookup more aggressively. notion of monolithic objects is roughly analogous to our notion of concatena- 3.3 Direction and Completion of Message tion, whereas his multiobjects represent Lookup the use of delegation (see also Sakkinen [1989]). Perfection is achieved only on the point of col- The main differences between delega- lapse. tion and concatenation have been gath- —C.N. PARKINSON ered into Table I. Most of the differ- ences between the approaches pertain In Section 2.3.2 we described the general to the treatment of inheritance graphs message sending algorithm that can be (DAGs). Delegation preserves inheri- seen as underlying all inheritance mecha- tance DAGs without modifications, but nisms. The algorithm consisted of four concatenation requires DAGs to be flat- elements—SEND, LOOKUP, CALL and tened out into contiguous name spaces. ERROR—that were intentionally defined This flattening implicitly prevents haz- somewhat vaguely. In particular, the ardous cycles in inheritance DAGs, but LOOKUP part of the algorithm simply at the same time it causes some impor- stated that as part of message matching tant differences in the usage of these the inheritance DAG will be traversed models. The notions of life-time sharing node by node. We did not, however, spec- and creation-time sharing mentioned in ify what the actual traversal order is. the table will be defined later in Section Neither did we completely specify when 3.8. this lookup will eventually end. For ex- Delegation and concatenation both ample, if the DAG contains several over- have certain advantages over each lapping identifiers, it is unclear which other. For instance, owing to dependent one of these properties should be invoked, interfaces, delegation enables flexible or should they all become invoked. In the propagation of change: any change to latter case it would be important to spec- parents will be automatically reflected ify also the exact order in which all these to descendants. This can be extremely overlapping properties are to be executed. useful at times, allowing a large group Moreover, in case of multiple inheritance of objects to be modified simply by the overlapping of identifiers is often in- changing a common parent. On the advertent, and the undesired identifier other hand, thanks to self-contained in- name collisions should somehow be taken terfaces, concatenation supports inde- into account. These issues will be ad- pendent modification of object inter- dressed in this and the next section. Note faces, making possible renaming and that all these questions apply equally to selective inheritance (Section 3.6). As for class-based and prototype-based systems, efficiency, delegation is generally more regardless of whether they are based on space-efficient due to extensive use of delegation or concatenation. sharing, but concatenation is generally In most contemporary object-oriented more time-efficient since the absence of systems the message lookup proceeds

ACM Computing Surveys, Vol. 28, No. 3, September 1996 462 • Antero Taivalsaari from the most recently defined (descen- ride the behavior inherited from par- dant) parts of objects towards the least ents, thereby providing additional sup- recently defined parts (parents). For ex- port for maintaining the behavioral ample, the behavior of message lookup compatibilities between parents and de- in Smalltalk has been described infor- scendants. mally as follows [Goldberg and Robson The distinction between descendant- 1989, p. 61]: “When a message is sent, driven and parent-driven lookup the methods in the receiver’s class are schemes is illustrated in Figure 10. searched for one with a matching selec- Note that the parent-driven lookup tor. If none is found, the methods in scheme is not really suited to systems that class’s superclass are searched with multiple inheritance, because in next. The search continues up the su- such systems inheritance DAGs do not perclass chain until a matching method necessarily have any single root node is found”. Thus, in Smalltalk message from which the lookup could be started. lookup always has a specific direction, Besides the differences in the direc- and will terminate as soon as the first tion of message lookup, the inheritance matching property is found. This con- scheme of Beta deviates from main- vention is used in various other object- stream object-oriented languages also in oriented languages including Cϩϩ and other ways. One important difference Eiffel, except that in many systems pertains to the completion or exhaustion multiple inheritance makes things of message lookup. In most object-ori- somewhat more complicated. Since the ented systems message lookup is termi- lookup is dominated by the most re- nated as soon as a matching property cently defined parts of objects, i.e., has been found and executed. If the those properties that have been defined programmer wants to execute the over- at the descendant level, we call this ridden properties inherited from the scheme descendant-driven inheritance. parents, it is the programmer’s respon- As usual, there are some interesting sibility to explicitly do so by defining variations. Beta [Kristensen et al. 1983; the methods to explicitly call the meth- Madsen and Møller-Pedersen 1989], a ods of their parents. Many object-ori- descendant of Simula, uses a totally op- ented languages provide a special super- posite parent-driven lookup scheme. In reference exactly for this purpose, as Beta, property lookup is started from discussed earlier in this paper. the topmost superpattern (the Beta Beta addresses the lookup exhaustion equivalent of superclass) in the current issue differently. In Beta, the overlap- inheritance DAG. Beta supports single ping (“extended”) properties in subpat- inheritance only, so this topmost super- terns will always be invoked automati- pattern is always unique, and the inher- cally without programmer intervention. itance DAG can be seen simply as a After finding and executing a matching linear path from parents to descen- property, the lookup will be continued dants. When a message is sent to an implicitly in the parent-driven lookup object (in Beta terminology: a virtual order until all the corresponding prop- procedure is invoked), lookup proceeds erties in the object have been executed. from the virtual procedures defined in This is essentially different from main- the topmost superpattern towards more stream object-oriented systems in which recently defined superpatterns of the even one matching property will suffice object until a matching procedure is to terminate the lookup. As noted by found. This matching procedure will Madsen and Møller-Pedersen, the then be invoked in the normal manner. Smalltalk-style of terminating the Since superpatterns have precedence lookup immediately after encountering over their subpatterns, the Beta-style the first matching method is more flexi- reverse inheritance strategy ensures ble, but is also a potential source of that descendants can never totally over- errors since the programmer may forget

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 463

Figure 10. Descendant-driven and parent-driven forms of inheritance.

to execute the corresponding property in be executed. In Table II, x is the prop- the superclass [Madsen and Møller-Ped- erty to be executed, and P and R denote ersen 1989]. the sets of properties defined at the Theoretically, the direction and ex- parent and child level, respectively. A haustion issues are closely related to special operation o is used to denote record combination. In his thesis, Cook execution ordering; for instance, aob [1989, p. 10] suggested that a distinc- implies that both a and b are executed, tion be made between left preferential but a is invoked before b. and right preferential record combina- Note that although the inheritance tion in order to specify the precedence of scheme of Beta is radically different from message lookup. However, since the than in most other object-oriented sys- terms left and right are quite imprecise tems, these systems are typically capable and open to interpretations, the terms of simulating each other quite easily. In parent and descendant are used here in Smalltalk, for instance, Beta’s composing the same meaning. In general, theoreti- message lookup scheme can be simu- cally we can make a distinction between lated simply by systematically placing five basic inheritance (record combina- an explicit super-reference within every tion) schemes, as illustrated in Table II. method. Moreover, if these super-refer- Strict record combination refers to situ- ences are always positioned in the begin- ations in which overlapping property ning of each method, the lookup order names are strictly forbidden. Asymmet- becomes logically parent-driven, even ric combination (see Harper and Pierce though the physical search order still re- [1991]) refers to such schemes in which mains descendant-driven. The same tech- the lookup is limited to the first match- nique can be used in Beta which provides ing property. Composing combination a special inner construct for controlling requires all the matching properties to the order of subpattern execution [Kris-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 464 • Antero Taivalsaari

Table 2. Variations of record combination for message lookup

tensen et al. 1983; Madsen and Møller- It’s useful to the people that name them, I sup- Pedersen 1989]. The behavior of inner is pose. If not, why do things have names at all. analogous to that of super-reference, but —LEWIS CARROLL, Through the Looking Glass its direction is reverse. Rather than in- voking properties of superclasses, Beta’s A problematic issue pertaining to multi- inner construct invokes properties in sub- ple inheritance are name collisions.A patterns. Thus, by placing an inner-refer- name collision occurs when the inheri- ence in the beginning of each virtual func- tance DAG contains overlapping proper- tion in a Beta program, the lookup order ties and the property lookup algorithm becomes logically descendant-driven. is unable to decide which one of these to However, there is no easy way to simu- execute. Not all overlapping properties late asymmetric message lookups in Beta. result in name collisions, however. For There are also other techniques that example, in single inheritance the over- can be used to control the direction and lapping of properties is a natural result exhaustion of message lookup. In partic- of incremental modification: when a de- ular, mixin inheritance discussed in scendant redefines some of its inherited Section 3.7 allows all the inheritance properties to differentiate itself from its schemes listed in Table II to be simu- parent, the newly redefined properties lated flexibly; different schemes are naturally overlap with the inherited achieved simply by changing the order ones. This form of overlapping of prop- in which base classes and mixins are erties poses no problems for message combined. For a thorough discussion on lookup algorithms and is sometimes this idea, refer to Bracha and Cook called vertical overlapping (see Knudsen [1990]. Among the currently available [1988]). In multiple inheritance vertical object-oriented languages, the CLOS overlapping occurs analogously when system with its special before, after and two properties with the same name are around methods provides perhaps the located along the same path in an inher- most comprehensive facilities for deal- itance DAG. For example, in Figure 11a ing with the lookup direction and ex- identifier x in node D vertically overlaps haustion. For further information on with identifier x in its parent node A. these aspects of CLOS, see DeMichiel Problems arise when overlapping of and Gabriel [1987] and Keene [1989, pp. properties is horizontal. Horizontally 11–13, and 50]. overlapping identifiers are those that are located along distinct paths in an inheritance DAG (see property y in Fig- 3.4 Ordered Versus Unordered Inheritance ure 11b), and thus horizontal overlap- A name is a spoken sound significant by conven- ping can take place only in multiple tion, without time, none of whose parts is signifi- inheritance. Generally speaking, there cant in separation. are two basic approaches to dealing with name collisions: ordered and unor- —ARISTOTLE, De Interpretatione §2 dered inheritance [Chambers et al.

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 465

Figure 11. Vertically and horizontally overlapping identifiers.

1991]. Most Lisp-based systems such as a similar invocation from node F cer- Flavors [Moon 1986], CommonLoops tainly should. In order to be able to cope [Bobrow et al. 1986] and CLOS with these kinds of situations, some sys- [DeMichiel and Gabriel 1987; Keene tems have been augmented with quite 1989] obey ordered multiple inheritance complicated mechanisms and inheri- schemes. In these systems the inheri- tance rules. For example, an earlier ver- tance DAG is first somehow linearized, sion of Self included a special sender and the first matching property on this path tiebreaker rule for addressing this linear path will then be executed re- particular problem [Chambers et al. gardless of the other properties with the 1991]. For further information on the same name. In contrast, languages like treatment of name collisions, see partic- Trellis/Owl [Schaffert 1986], Eiffel ularly Knudsen [1988]. [Meyer 1988], Cϩϩ [Ellis and Strous- trup 1990] and CommonObjects [Snyder 3.5 Dynamic Inheritance 1986b] treat inheritance DAGs without any relative ordering. In these lan- Wood may remain ten years in the water, but it guages, name collisions are considered will never become a crocodile. programming errors, and any ambigu- —Congolese proverb ities must be resolved explicitly by the programmer. In Section 3.2 a distinction between two Note that not even horizontal overlap- fundamental strategies for implement- ping of properties should always be ing inheritance—delegation and concat- treated as a name collision. If two con- enation—was made. It was concluded ceptually unrelated abstractions are that both strategies have their own ben- combined using multiple inheritance, it efits that are difficult to capture using may well happen that these abstrac- the other strategy. In this section this tions accidentally contain overlapping discussion is taken a bit further by dis- identifiers [Chambers et al. 1991]. Since cussing dynamic inheritance: the ability the abstractions are conceptually unre- to change parents of objects dynami- lated, it is clear, however, that the oper- cally at runtime [Chambers et al. 1991; ations of these abstractions are not in- Stein et al. 1988]. Despite being intu- tended to access each others’ properties. itively a rather dangerous language fea- For instance, in the example above, the ture, dynamic inheritance provides late-bound invocation of property y via some notable benefits, and therefore, self-reference from node A or D should although dynamic inheritance has typi- not result in a name collision, although cally been available only in some proto-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 466 • Antero Taivalsaari type-based systems, it has recently cap- ple. In the design and implementation tured the interest of many researchers of programs we are often faced with of class-based systems as well. things and structures that can be in Recall from the earlier discussion that different states or conditions. In this delegation-based systems accomplish context we are not referring to the con- the interface combination required by crete state of the variables of these ob- incremental modification by sharing the jects, such as the integer 12345 in vari- interface of the parent, i.e., using refer- able foo, but rather to a more ences rather than copying. In class- conceptual or logical kind of state. For based systems, the references between instance, container objects such as children and parents are usually main- stacks, lists and queues can be empty, tained by the system and are completely nonempty or full. In graphical user in- inaccessible to the programmer. In con- terfaces, windows can usually be open, trast, in prototype-based systems these closed or represented as icons. Simi- references are typically implemented as larly, application-specific objects such parent slots. By giving these slots as bank accounts, flight reservations, or names, and by making them assignable, patient registers also exhibit many we allow the parents of objects to be kinds of logical states. The behavior of changed on the fly. Consider the follow- the operations of objects typically varies ing object definitions: considerably depending on these logical states. For instance, the behavior of the aPEN:-[VAR x, VAR y, METHOD draw]; pop operation of a stack depends essen- aTurtle:-[PARENT parent:-aPen, VAR tially on whether the stack contains heading, METHOD forward]; items or is empty; in the latter case pop Assuming that the parent slot parent must not return any value but rather behaves like an ordinary variable, we raise an error. Similarly, when a bank can dynamically change the parent slot account has been frozen by the bank, to refer to some other object. Below we the teller machine should not dispense define a new object a3dPen, supposedly any money when a withdrawal is re- representing a three-dimensional coun- quested but rather swallow the card. In terpart of aPen, and make this object conventional object-object systems, the parent of aTurtle. these kinds of logical states or modes,as they are sometimes called, are hard to a3dPen:- [VAR x, VAR y, VAR z, METHOD express. Usually, additional state vari- draw]; ables and control structures are needed. aTurtle.parent:- a3dPen; For instance, each of the basic window After these operations, the behavior manipulation operations such as open, of aTurtle is no longer the same as it close, iconify, resize and zoom typically was before. The object contains an extra has to contain an explicit if-statement variable z, and the actual method draw or case-statement to determine whether is different than before. As apparent, the operation is appropriate for the win- dynamic inheritance can be quite dan- dow in the current situation. Obviously, gerous. If the properties of the new par- the diffusion of mode information and ent do not comply with those needed by accumulation of control structures both the descendant, runtime binding errors tend to have a negative impact on the will result. Dynamic inheritance can readability and maintainability of code. also have a deteriorating effect on per- Dynamic inheritance provides a solu- formance, since the possibility to change tion to the problems with logical states. parents at runtime prevents certain Since the behavior of objects can be kinds of message lookup optimizations changed at runtime, not all the informa- from being done [Chamber et al. 1991]. tion about an object has to be described The benefits of dynamic inheritance in one class or prototype. Rather, by are best described by giving an exam- implementing a separate set of methods

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 467

Figure 12. Dynamic inheritance.

for each logical state, the behavior of tems. This is mainly due to the fact that each mode can be kept clearly apart in class-based systems classes describe from the others. Dynamic inheritance is not only behavioral but structural as- illustrated in Figure 12 in which we see pects as well; if the superclass of a class a window object with three parent ob- were suddenly changed at runtime, the jects (“traits” in Self terminology structure of the instance would likely be [Chambers et al. 1991]) representing incompatible the structure specified by the different logical states of windows the new superclass. The fact that most (open, closed, iconified). Each of the par- class-based systems do not support late ent objects implements the same basic binding of variables makes the situation set of methods, but the behavior of the even more problematic. Due to the ap- methods is specialized to each particu- parent benefits of modes, however, lar logical state. Initially the parent slot there have been some proposals on how of the prototype is set to point to traits to add corresponding mechanisms to OpenWindow, implying that only those class-based systems [Chambers 1993; operations that are applicable to open Stein 1989; Taivalsaari 1993b]. Among windows are available, but when the these, Chambers’ predicate classes seem logical state of the object changes at particularly promising. runtime, e.g., the window becomes closed, the parent slot is changed corre- 3.6 Selective Inheritance spondingly. Using this approach, method definitions can be kept concise Just as delegation enables dynamic in- and clear, because the methods in one heritance, concatenation gives rise to mode do not have to know how the other some interesting variations of inheri- modes behave. The number of control tance. For instance, the self-contained structures in programs is reduced sub- nature of object interfaces in concatena- stantially. tion has the advantage of making the Note that dynamic inheritance is not object interfaces independent of each typically possible in class-based sys- other. This possibility is utilized in

ACM Computing Surveys, Vol. 28, No. 3, September 1996 468 • Antero Taivalsaari

Eiffel, which allows the inherited prop- the actual method implementations and erties to be renamed in subclasses variable values are ignored. [Meyer 1988, pp. 246–250]. Renaming t1 :- [METHOD m1, VAR v1]; apparently requires that the inheri- t2 :- [METHOD m2, VAR v2]; tance mechanism is implemented using concatenation; otherwise the modifica- Suppose that we now define two other tion of inherited identifiers would not be objects t3 and t4 which make use of the possible without affecting superclasses. existing objects t1 and t2. Object t3 Besides allowing renaming, indepen- uses t1 and t2 as its parents, whereas dent interfaces have other benefits. In t4 uses t1 and t2 as its variables. Note particular, they make possible such that in this particular example t3 has forms of inheritance in which not all been implemented using delegation and properties of inherited abstractions t4 using reference variables, but the have to be passed to descendants. situation would be analogous using con- Rather, the descendant can be given the catenation and containment. explicit possibility to decide which par- t3 :-[PARENT p1 :- t1, PARENT p2 :- t2, ticular properties of parents to inherit METHOD m3, VAR v3]; and which not. Such forms of inheri- t4 :-[VAR p1 :- t1, VAR p2 :- t2, METHOD tance are said to represent selective in- m3, VAR v3]; heritance [Wilkes 1988]. Selective inher- Basically, the only difference between itance has been tried out in Sina/St objects t3 and t4 pertains to how their [Aksit and Tripathi 1988], a Smalltalk- properties can be accessed. In case of t3 based system that dispenses with (t1 and t2asparents), the properties of classes and uses a two-level type con- t1 and t2 can be accessed directly with- cept with separate interfaces and imple- out having to mention the intervening mentations instead. At the level of type identifiers p1 and p2. In case of t4(t1 interfaces, the programmer can explic- and t2asvariables), the intervening itly select which properties of objects to identifiers along the access path to inherit and which not. The Kevo system properties m1, v1, m2 and v2 must be [Taivalsaari 1993c] also supports selec- mentioned explicitly. For example, the tive inheritance through its partial re- following expressions use mechanisms. One of the interesting theoretical as- t3.m1; pects of selective inheritance is that it t3.v2; shows that the difference between in- are legal, whereas the corresponding heriting an abstraction (such as a class messages to t4 would lead to binding or a prototype) and using the abstrac- errors. Thus, for t4 the intervening tion as a variable is actually very sub- identifiers p1 and p2 must be used as tle. From the interface combination shown below. viewpoint the only difference between these is that in the former case the t4.p1.m1; property names of the inherited compo- t4.p2.v2; nent are implicitly included into the Note that in the presence of selective interface of the descendant, and thus inheritance the distinction between par- the inherited properties can be referred ents and variables becomes blurred. Se- to directly. In contrast, in the latter lective inheritance allows only a subset of case the properties are not included and the identifiers of parents to be brought must be accessed indirectly via an inter- into the interface of the descendant, and vening variable. As an example of this, hence the degree of “parentness” and consider the following example. Assume “variableness” can be varied. In particu- that we have the following objects t1 lar, if a language provides a mechanism and t2 defined in our system. Since we by using which any uniquely named prop- are dealing with interface aspects only, erty within an object can be accessed di-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 469

Figure 13. Ordinary inheritance versus mixin inheritance.

rectly without having to specify the full 3.7 Mixin Inheritance path to it, then from the viewpoint of Mixin inheritance is a certain way of interface management the distinction be- using inheritance that has received tween variables and parents will vanish quite a lot of attention in the literature altogether. This idea is utilized in Sina/St of object-oriented programming [Bracha where multiple inheritance is achieved 1992; Bracha and Cook 1990; Hendler simply by declaring multiple variables at 1986]. This is not surprising, consider- the interface of a type and making the ing that mixin inheritance has certain properties of these variables directly ac- important theoretical and pragmatic cessible by means of an appropriate pred- benefits. On the theoretical side, mixin icate [Aksit and Tripathi 1988]. Of inheritance has been proven to be capa- course, in most object-oriented languages ble of capturing the functionality of sev- encapsulation (information hiding) eral other forms of inheritance [Bracha changes the picture to some extent, since and Cook 1990]. Therefore, mixin inher- not all variables or methods may be ac- itance is sometimes regarded as a more cessible to outside clients due to being “elementary” form of inheritance that declared private. can provide help in understanding the The use of selective inheritance can other forms. On the pragmatic side, lead to some conceptual and technical mixin inheritance is beneficial because problems. In particular, incautious it can considerably improve the reus- omission of inherited properties can ability of program components. produce objects whose interfaces are in- The basic idea of mixin inheritance is complete, and that do not possess all simple. Unlike in ordinary inheritance, the properties to which their operations in which the modification (delta) parts need access. Therefore, additional in class definitions are embedded di- mechanisms may have to be introduced rectly in the new definitions (see Figure to guarantee the completeness of ob- 13a), in mixin inheritance separate jects. For further information on selec- mixin classes are created to hold the tive inheritance, refer to Aksit and Tri- modifications [Bracha and Cook 1990; pathi [1988], Cook [1989a] and Wilkes Hendler 1986]. A mixin class is syntac- [1988]. tically identical to a normal class, but

ACM Computing Surveys, Vol. 28, No. 3, September 1996 470 • Antero Taivalsaari its intent is different. Such a class is ment (see, e.g., Bracha and Cook created solely to be used for adding [1990]). properties to other classes—one never Mixin inheritance is not without prob- creates an instance of a mixin. New lems. From the conceptual point of view, concrete classes, such as class R in Fig- one of the less beneficial characteristics ure 13b, are constructed by combining of mixin inheritance is that it tends to primary parent classes (class P in Fig- cause confusion in the relationship of ure 13b) with secondary mixin classes object-oriented programming and con- (R_Mixin) using multiple inheritance. ceptual modeling by diversifying the Since mixin classes do not have su- role of classes. As apparent in Figure perclasses and are not therefore struc- 13b, in mixin inheritance classes are turally bound to any specific place in used for three distinct purposes. First, the inheritance hierarchy, the same there are base classes that define the modifications (delta parts) can be re- general characteristics of a hierarchy of peatedly used (inherited) without hav- concepts. These classes are either con- ing to rewrite or copy their contents crete instantiable classes, or abstract manually when similar modifications noninstantiable classes that exist solely are needed in other places [Bracha and to be refined by their subclasses. Sec- Cook 1990]. This enhances reusability ond, there are mixin classes that serve by allowing the same functionality to be as elementary units of reusable behav- flexibly added to various components. ior. Mixin classes cannot be used in Using single inheritance in a similar isolation but must first be combined situation, considerable code duplication with a concrete class to become func- would result because the same pieces of tional; therefore, mixin classes are sometimes referred to as abstract sub- code would have to be repeatedly writ- classes [Bracha and Cook 1990]. Third, ten in several classes. Ordinary multi- mixin-based systems also have combi- ple inheritance would usually suffice to nation classes that are needed for in- solve the problem, too. However, ordi- stantiating concrete instances with the nary multiple inheritance is prone to desired functionality. cause difficulties if the same classes be- In summary, mixin inheritance can come inherited two or more times along considerably increase the reusability of different inheritance paths (e.g., class class definitions, but at the same time it has two superclasses that have a com- may decrease the conceptual clarity of mon superclass). As already mentioned the system by requiring the same class earlier in the article, this problem is mechanism to be used for three differ- commonly referred to as repeated inher- ent purposes in a rather subtle and itance [Meyer 1988, pp. 274–279], fork- unintuitive way. In this sense, mixin join inheritance [Sakkinen 1989], or dia- inheritance serves as a practical exam- mond inheritance [Bracha 1992, pp. ple of the fact that reusability and con- 24–26]. ceptual modeling are opposite goals:in Note that in mixin inheritance multi- order to obtain maximum reusability, ple inheritance is used strictly for com- one usually has to sacrifice modeling, binatory purposes. Provided that the and vice versa. For further information mixin classes are implemented cor- on mixin inheritance, refer to Bracha rectly, no additional manual “gluing” is and Cook [1990]. needed when base classes and mixins are inherited (combined). In practice 3.8 Life-Time Sharing Versus Creation- this requires that the methods of mixin Time Sharing classes are implemented in such a way that they are open to extensions, and Inheritance is a familiar concept from remember to invoke the corresponding the real world. All living organisms in- methods in their surrounding environ- herit genetic information from their an-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 471 cestors, and thus inheritance serves as parents and children to physically share one of the fundamental mechanisms for organs with each other. maintaining life on earth. Besides its In object-oriented programming the biological meaning, the term inheri- meaning of inheritance is somewhat dif- tance has various uses in human lan- ferent. Although inheritance still basi- guages. For instance, it is common to cally implies receiving, in object-ori- speak of cultural inheritance (“Aborigi- ented programs inheritance usually nals inherited their traditions and cus- creates much stronger relationships be- toms from their ancestors”), economic tween things than in the real world. For inheritance (“Frank inherited a lot of instance, when a subclass inherits prop- money from his aunt”), inheritance of erties from its superclass, it is common status (“princess Victoria inherited her that the methods of the superclass are rank from her father, the king of Swe- made available to the subclass by phys- den”) and so on. The term inheritance ically sharing the same code. Although can also have more colloquial uses such such “Siamese” sharing is alien to bio- as “this paper inherited a lot of ideas logical inheritance, it is reasonable in from my earlier work.” All these uses of programming, because requiring every- the term inheritance have certain thing to be duplicated in the subclass things in common. In particular, inheri- would waste a lot of memory. Snyder tance is synonymous with receiving;in has expressed this by claiming that “a most sentences the verb inherit could be key goal for any implementation of an replaced with receive and the meaning object-oriented language is to allow the of the sentence would remain the same. same compiled code to be used for each Note that receiving implies that there class that inherits a given method” must necessarily be at least two sepa- [Snyder 1986b]. Not all inheritance in rate entities—the donor and the receiv- object-oriented programming results in er—that participate in the inheritance physical sharing, however. For instance, process. the instance variables in instances of A characteristic aspect of inheritance classes are always distinct from those in is sharing. As a result of inheritance, the instances of superclasses. the donor and receiver are expected to From the theoretical viewpoint, it is share something with each other. Shar- useful to make a distinction between ing need not be physical, however. For two fundamental forms of sharing that instance, although it is common to say serve as a basis for property inheri- that the child “shares the blue eyes of tance: life-time sharing and creation- his father”, it does not mean that the time sharing. Life-time sharing refers to father and child will have to use the physical sharing between parents and same pair of eyes. Similarly, although children. Once the sharing relationship identical twins “share” the same genetic between parent and child has been es- information, they are nevertheless two tablished, the child remains sharing the separate persons. In general, in its real properties of its parent until the rela- world meaning, inheritance usually re- tionship is removed. Furthermore, every fers to very transitory relationships be- change to the parent is implicitly re- tween things. In biological inheritance, flected to the child. Creation-time shar- for instance, the combination of genetic ing, in turn, implies that sharing occurs information takes place within a short only while the receiving process is in period of time, and the resulting new progress. Creation-time sharing is char- “abstraction” later becomes completely acterized by the independent evolution independent of its parent (well, at least of the parent and the child, and is typi- in principle, although in case of human cal of the real world. Delegation dis- beings the economic ties usually re- cussed in Section 3.2 results in life-time main. . .). This independence is reason- sharing, whereas concatenation results able, because it would be impractical for in creation-time sharing. The notions of

ACM Computing Surveys, Vol. 28, No. 3, September 1996 472 • Antero Taivalsaari life-time sharing and creation-time determines the method that is invoked sharing were introduced by Dony et al. by the message. The possible parame- [1992], who realized that these concepts ters in the message are passed on to the are useful in analyzing the differences invoked method, but do not participate between various prototype-based object- in the actual lookup. Although this ap- oriented systems. proach is intuitive and works well in The forms of sharing have a profound most situations, it has some drawbacks. effect on the semantics of object-ori- For instance, one implication is that a ented languages. Generally speaking, binary expression such as “5ϩ4” gets inheritance in real-world object-ori- the unnatural interpretation. ented languages can occur at three dif- ferent levels: behavior, state and struc- 5.plus(4). ture. Inheritance of behavior refers to In other words, 5 is treated as the re- the passing of operations from parents ceiver of the message plus, while 4 is to their children. Since operations are regarded as a parameter that plays no typically immutable, in many cases this role in actual method lookup. Although can be accomplished simply by sharing such “currying” works fine in most situ- code. Inheritance of state, in turn, refers ations, it is conceptually undesirable to the passing of contents (values) of since in arithmetic expressions right variables from parents to the children. hand sides are usually no less impor- This can imply either sharing or dupli- tant than left hand sides. It can also cation, depending on what is appropri- have a negative effect on program read- ate in each particular situation. Sharing ability. For instance, in Smalltalk all of state leads to objects whose states are binary expressions are parsed left to intimately connected to each other and right, and normal arithmetic precedence which thus are dependent on each other. rules do not apply. This makes mathe- Duplication of state, on the other hand, leads to independent objects [Stein matical expressions in Smalltalk differ- 1987]. Note that inheritance of state is ent from those in most other languages not typically possible in class-based sys- in which multiplication and division tems, because in such systems inheri- take precedence over addition and sub- tance occurs between definitions of ob- traction [Goldberg and Robson 1989, p. jects (i.e., classes) rather than between 28]. objects themselves. Instead, class inher- Besides conceptual problems, single itance supports inheritance of structure, dispatching can also lead to some more by which it is meant that normally only technical problems and require duplica- the information that is needed for re- tion of code. In order to make single constructing (allocating) the inherited dispatching handle properly situations instance variables is passed to descen- in which the same type of object may dants. This implies that there must be receive different kinds of parameters, an additional mechanism to pass infor- the use of additional control structures mation about instance variables to sub- is usually needed. For instance, sending classes. Some prototype-based lan- a message “5 ϩ 4.4” requires the integer guages provide special copy-down slots method ϩ to be able to check at runtime for this purpose. whether the parameter is an integer or a floating point number, and handle both integer and floating point addition. 3.9 Single Dispatching Versus Multiple Conversely, since it is equivalently legal Dispatching for the programmer to send a message Most object-oriented systems are based “4.4 ϩ 5,” the floating point class must on single dispatching. Messages are include the corresponding code to han- sent to distinguished receiver objects, dle both real numbers and integers. As and the runtime type of the receiver a result, the same pieces of code may

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 473 have to be included in two places, or, if oriented.” This feeling reflects a basic the message is nary rather than binary, difference in the programming styles in n places. encouraged by single and multiple dis- In general, traditional message pass- patching systems [Chambers 1992]. ing schemes are sometimes too “selfish.” When using a single dispatching lan- There is a single receiver whose type guage, the programmer mentally fo- determines which method is executed, cuses on defining abstract data types while the parameters are ancillary and (ADTs), associating operations with the have no role in method selection. An data types for which they are imple- object-oriented language based on this mented. These operations are “con- kind of an approach is termed a single tained” in the data type, and together dispatching language. In many situa- the operations and the data form an tions, however, it would be beneficial to encapsulated whole. A whole design and generalize the message binding mecha- implementation methodology has been nism to more than just single receiver. developed around this ADT-oriented To surmount the limitations of single programming style. dispatching languages, some object-ori- Multiple dispatching languages do ented languages include a more general not provide much linguistic support for form of message passing in which multi- the ADT-oriented programming style. ple arguments to a message can partici- Since multimethods are dispatched on pate in the lookup process. These lan- multiple arguments, they are not con- guages are called multiple dispatching tained in any single class, and the ADT- languages. Since methods in multiple oriented view with strong encapsulation dispatching languages may belong to breaks down. In practice, the program- several classes simultaneously, they are ming style encouraged by multiple dis- called multimethods. Multiple dispatch- patching systems seems to be closer to ing is common in Lisp-based object-ori- functional, or traditional procedural ented systems, where multimethods are programming style than ADT style. To known as generic methods [DeMichiel many advocates of object-oriented pro- and Gabriel 1987]. Multimethods were gramming, multimethods—having origi- pioneered in CommonLoops [Bobrow et nated from Lisp-based systems—seem al. 1986], but the best-known multiple like an ad hoc solution that is a conse- dispatching object-oriented language of quence of trying to fit round objects to today is CLOS [DeMichiel and Gabriel the square world of functions. This feel- 1987; Keene 1989]. ing is reinforced by the fact that multi- Some researchers claim that multiple methods do not “look object-oriented” dispatching provides increased expres- either. In multiple dispatching lan- sive power over single dispatching guages the use of the object-oriented [Chambers 1992]. With multimethods, object.message(parameters) notation is the message lookup may involve all ar- discouraged, and the traditional func- guments, not just the receiver, and thus tion(parameters) or Lisp-like (function the above mentioned problems with the param1 ... paramN) notation is used “asymmetry” of single dispatching can instead. Although some researchers be avoided. Multiple dispatching is far have proposed (receiver1, receiver2, ..., from being widely accepted, however. receiverN).message notation as a com- Multiple dispatching languages are gen- promise, these notations are not as well erally more complex than single dis- suited to ADT programming style as the patching languages, and their imple- normal dot notation or its equivalents. mentations have not traditionally been Recently Chambers, one of the origi- very efficient. In practice, the biggest nal implementors of the Self language single concern to the programmers is [Ungar and Smith 1987], has spoken however that languages supporting strongly in favor of multimethods multiple dispatching do not “feel object- [Chamber 1992]. One of Chambers’

ACM Computing Surveys, Vol. 28, No. 3, September 1996 474 • Antero Taivalsaari main arguments is that problems with incremental modification. If this cri- multiple dispatching arise mainly from terion is not fulfilled, then we are the limitations of text-based program- not talking about inheritance in the ming, and by providing a good graphical object-oriented sense. programming environment, most of the (2) Interface inheritance. At this level, problems with multimethods disappear. inheritance is viewed as an interface Instead of placing multimethods outside combination or name space combi- of any single class, or by duplicating the nation mechanism. Questions per- same definition in every participating taining to the management of the class, a good visual browser would auto- actual properties (methods and vari- matically display the same multimethod ables) of objects are ignored. in association with all its classes. Intu- (3) Property inheritance. The actual itively, this sounds like a good idea, but properties (methods and variables) it still remains to be seen whether mul- of objects are included in the analy- tiple dispatching really catches on in sis. the object-oriented community. Figure 14 gives an overview of the issues and sources of variability that 3.10 Classifying Inheritance Mechanisms arise at each level. For a more detailed Earlier in the article we saw that while treatment on the subject, refer to inheritance is a simple linguistic mech- Taivalsaari [1993c]. anism with relatively straightforward semantics from the theoretical point of 4. CONCLUSION view, many variations of inheritance ex- ist that tend to make the analysis of Broadly speaking, the history of software develop- inheritance difficult in practice. In addi- ment is the history of ever-later binding time. tion to basic questions—such as —Encyclopedia of Computer Science whether the system is based on classes or prototypes, or whether it supports In this article we have surveyed the single or multiple inheritance—there is notion of inheritance, examining its in- a large number of more elementary is- tended and actual usage, its essence sues that have a considerable impact on and its varieties. We realized that al- the semantics and pragmatics of the though inheritance was originally intro- system. When implemented in concrete duced as a mechanism to support con- object-oriented programming languages, ceptual specialization, in reality many typically these mechanisms tend to in- alternative roles for inheritance can be terfere with each other, making the recognized, ranging from conceptual analysis and comparison of the lan- modeling to implementation-level usage guages complicated. (e.g., using inheritance simply as a code In trying to understand the concrete sharing mechanism to save storage realizations of inheritance in object-ori- space or programming effort). Also, we ented programming languages, it is use- pointed out that there is no single, com- ful to use a progressive approach, i.e., to monly accepted model of inheritance, start from conceptually simpler issues but a lot of variations of the same basic and then gradually progress towards theme exist. more complicated aspects. The following The fundamental observation under- kind of three-level taxonomy has proved lying object-oriented inheritance mecha- helpful in analyzing inheritance in ob- nisms is that they all are essentially ject-oriented programming languages. incremental modification mechanisms, i.e., mechanisms that allow existing (1) Inheritance as incremental modifi- programs to be extended and refined cation. As discussed in Section without editing existing code. In gen- 2.3.1, the “core” of inheritance is eral, inheritance can be defined gener-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 475

Figure 14. A simple taxonomy for analyzing inheritance mechanisms.

ally as an incremental modification REFERENCES mechanism in the presence of late-bound AKSIT,M.AND TRIPATHI, A. 1988. Data abstraction self-reference. Although object-oriented mechanisms in Sina/st. In OOPSLA’88 Con- programming has many other benefits ference Proceedings (San Diego, California, compared to other programming para- Sept. 25–30). ACM SIGPLAN Not. 23, 11 digms, none of them seems as profound (Nov.), 267–275. as the incremental capability. To con- AMERICA, P. 1987. Inheritance and subtyping in a clude, let us quote Stein et al. [1988] parallel object-oriented language. In ECOOP ’87: European Conference on Object-Oriented who have noted that “the true value of Programming (Paris, France, June 15–17). object-oriented techniques as opposed to Lecture Notes in Computer Science 276, conventional programming techniques Springer-Verlag, 234–242. is not that they can do things the con- AMERICA, P. 1990. Designing an object-oriented pro- ventional techniques can’t, but that gramming language with behavioural subtyping. they can often extend behavior by add- In Proceedings of the Foundations of Object-Ori- ing new code in cases where conven- ented Languages, REX School/Workshop.J.W. De Bakker, W. P. De Roever, G. Rozenberg, Eds. tional techniques would require editing (Noordwijkerhout, The Netherlands, May existing code instead.” This captures 28–June 1). Lecture Notes in Computer Science the heart of the matter. 489, Springer-Verlag, 1991, 60–90.

ACM Computing Surveys, Vol. 28, No. 3, September 1996 476 • Antero Taivalsaari

BLASCHEK, G. 1991. Type-safe OOP with proto- Lecture Notes in Computer Science 615, types: the concepts of Omega. Structured Pro- Springer-Verlag, 33–56. gram. 12, 12 (Dec.) 1–9. CHAMBERS, C. 1993. Predicate classes. In BLASCHEK, G. 1994. Object-Oriented Programming ECOOP’93: European Conference on Object- with Prototypes. Springer-Verlag. Oriented Programming (Kaiserslautern, Ger- BOBROW, D. G., KAHN, K., KICZALES, G., MASINTER, many, July 26–30). Lecture Notes in Com- L., STEFIK,M.AND ZDYBEL, F. 1986. Common- puter Science 707, Springer-Verlag, 268–296. Loops: merging Lisp and object-oriented pro- CHAMBERS, C., UNGAR, D., CHANG, B.-W. AND gramming. In OOPSLA’86 Conference Pro- HO¨ LZLE, U. 1991. Parents are shared parts of ceedings (Portland, Oregon, Sept. 26–Oct. 2). objects: inheritance and encapsulation in Self. ACM SIGPLAN Not. 21, 11 (Nov.), 17–29. Lisp Symbolic Comput. 4, 3 (Jun.). BORGIDA, A., MYLOPOULOS,J.AND WONG, H.K.T. COOK, W. R., HILL,W.L.AND CANNING, P. S. 1990. 1984. Generalization/specialization as a basis Inheritance is not subtyping. In Proceedings for software specification. In On Conceptual of the Seventeenth Annual ACM Symposium Modelling: Perspectives from Artificial Intelli- on Principles of Programming Languages gence, Databases, and Programming Lan- (San Francisco, California, Jan. 17–19), ACM guages, M. L. Brodie, J. Mylopoulos, J. W. Press, 125–135. Schmidt, Eds. Springer-Verlag, 87–117. COOK, W. R. 1989. A denotational semantics of BORNING,A.H.AND O’SHEA, T. 1987. Deltatalk: an inheritance. Ph.D. thesis, Brown University, empirically and aesthetically motivated sim- Tech. Rep. CS-89-33, May. plification of the Smalltalk-80 language. In COOK, W. R. 1989. A proposal for making Eiffel ECOOP’87: European Conference on Object- type-safe. Comput. J. 32, 4 (Aug.), 305–311. Oriented Programming (Paris, France, June Also in ECOOP’89: Proceedings of the Third 15–17). Lecture Notes in Computer Science European Conference on Object-Oriented Pro- 276, Springer-Verlag, 1–10. gramming (Nottingham, England, July 10– 14). The British Computer Society Workshop BORNING, A. H. 1986. Classes versus prototypes in object-oriented languages. In Proceedings of Series, Cambridge, Univ. Press, 57–70. ACM/IEEE Fall Joint Computer Conference, COOK, W. R. 1992. Interfaces and specifications (Nov.) 36–40. for the Smalltalk-80 collection classes. In OOPSLA’92 Conference Proceedings (Vancou- BRACHA, G. 1992. The programming language Jig- ver, Canada, Oct. 18–22). ACM SIGPLAN saw: Mixins, modularity and multiple inheri- Not. 27, 10 (Oct.), 1–15. tance. Ph.D. thesis, Univ. of Utah, March. COOK,W.R.AND PALSBERG, J. 1989. A denota- BRACHA,G.AND COOK, W. 1990. Mixin-based in- tional semantics of inheritance and its cor- heritance. In OOPSLA/ECOOP’90 Conference rectness. In OOPSLA’89 Conference Proceed- Proceedings (Ottawa, Canada, Oct. 21–25). ings (New Orleans, Louisiana, Oct. 1–6). ACM SIGPLAN Not. 25, 10 (Oct.), 303–311. ACM SIGPLAN Not. 24, 10 (Oct.), 433–443. BRACHA,G.AND LINDSTROM, G. 1992. Modularity DAHL, O-J., DIJKSTRA,E.W.AND HOARE, C.A.R. meets inheritance. In Proceedings of the 1992 1972. Structured Programming. Academic International Conference on Computer Lan- Press. guages (Oakland, California, April 20–23), DAHL, O-J., MYHRHAUG,B.AND NYGAARD, K. 1968. IEEE Computer Society Press, 282–290. SIMULA 67 common base language. Tech. BRACHMAN, R. 1983. What Is-a is and isn’t? IEEE Rep., Norwegian Computing Center, Oslo, Comput. 16, 10 (Oct.) 30–36. May. BRACHMAN, R. 1985. I lied about the trees—or, DANFORTH,S.AND TOMLINSON, C. 1988. Type theo- defaults and definitions in knowledge repre- ries and object-oriented programming. ACM sentation. AI Magazine 6, 3 (Fall) 80–93. Comput. Surv. 20, 1 (Mar.) 29–72. BRODIE, M. L. 1983. Association: a database ab- DEMICHIEL,L.G.AND GABRIEL, R. P. 1987. The straction for semantic modelling. In Entity- Common Lisp object system: An overview. In Relationship Approach to Information Model- ECOOP’87: European Conference on Object- ing and Analysis. P. P. Chen, Ed. Elsevier Oriented Programming (Paris, France, June Science Publishers (North-Holland), 577–602. 15–17). Lecture Notes in Computer Science CARDELLI, L. 1984. A semantics of multiple inher- 276, Springer-Verlag, 157–170. itance. In Semantics of Data Types, G. Kahn, DEUTSCH,L.P.AND SCHIFFMAN, A. M. 1984. Effi- D. B. MacQueen, G. Plotkin, Eds. Lecture cient implementation of the Smalltalk-80 sys- Notes in Computer Science 173, Springer-Ver- tem. In Proceedings of the Eleventh Annual lag, 51–67. ACM Symposium on Principles of Program- CHAMBERS, C. 1992. Object-oriented multi-meth- ming Languages (Salt Lake City, Utah, Jan. ods in Cecil. In ECOOP’92: European Confer- 15–18), ACM Press, 297–302. ence on Object-Oriented Programming (Utre- DONY, C., MALENFANT,J.AND COINTE, P. 1992. cht, The Netherlands, June 29–July 3). Prototype-based languages: from a new taxon-

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 477

omy to constructive proposals and their vali- guage. In Proceedings of the Tenth Annual dation. In OOPSLA’92 Conference Proceedings ACM Symposium on Principles of Program- (Vancouver, Canada, Oct. 18–22). ACM SIG- ming Languages (Austin, Texas, Jan. 24–26), PLAN Not. 27, 10 (Oct.), 201–217. ACM Press, 285–298. DRIESEN, K., HOLZLE¨ ,U.AND VITEK, J. 1995. Mes- KNUDSEN,J.L.AND MADSEN, O. L. 1988. Teaching sage dispatch on pipelined processors. In object-oriented programming is more than ECOOP’95: European Conference on Object- teaching object-oriented programming lan- Oriented Programming (Åarhus, Denmark, guages. In ECOOP’88: European Conference Aug. 7–11). Lecture Notes in Computer Sci- on Object-Oriented Programming (Oslo, Nor- ence. 952, Springer-Verlag, 253–282. way, Aug. 15–17). Lecture Notes in Computer DUCOURNAU,R.AND HABIB, M. 1987. On some Sci. 276, Springer-Verlag, 21–40. algorithms for multiple inheritance in object- KNUDSEN, J. L. 1988. Name collision in multiple oriented programming. In ECOOP’87: Euro- classification hierarchies. In ECOOP’88: Eu- pean Conference on Object-Oriented Program- ropean Conference on Object-Oriented Pro- ming (Paris, France, June 15–17). Lecture gramming (Oslo, Norway, Aug. 15–17). Lec- Notes in Computer Science 276, Springer-Ver- ture Notes in Computer Sci. 276, Springer- lag, 243–252. Verlag, 93–109. ELLIS,M.A.AND STROUSTRUP, B. 1990. The Anno- KORSON,T.AND MCGREGOR, J. D. 1990. Under- tated Cϩϩ Reference Manual. Addison-Wesley. standing object-oriented: A unifying para- GOLDBERG,A.AND ROBSON, D. 1989. Smalltalk-80: digm. Commun. ACM 33, 9 (Sept.) 40–60. The Language. Addison-Wesley. KRUEGER, C. W. 1992. Software reuse. ACM Com- GRAVER,J.O.AND JOHNSON, R. E. 1990. A type put. Surv. 24, 2 (June) 131–183. system for Smalltalk. In Proceedings of the LALONDE, W. R. 1989. Designing families of data Seventeenth Annual ACM Symposium on types using exemplars. ACM Trans. Program. Principles of Programming Languages (San Lang. Syst. 11, 2 (Apr.) 212–248. Francisco, California, Jan. 17–19), ACM Press, 136–150. LALONDE,W.R.AND PUGH, J. 1991. Subclassing Þ subtyping Þ is-a. J. Object-Oriented Program. HALBERT,D.C.AND O’BRIEN, P. D. 1987. Using 3, 5 (Jan.), 57–62. types and inheritance in object-oriented pro- gramming. IEEE Softw. 4, 5 (Sept.), 71–79. LALONDE, W. R., THOMAS,D.A.AND PUGH,J.R. Revised version in ECOOP’87: European Con- 1986. An exemplar based Smalltalk. In ference on Object-Oriented Programming (Par- OOPSLA’86 Conference Proceedings (Port- is, France, June 15–17). Lecture Notes in land, Oregon, Sept. 26–Oct. 2). ACM SIG- Computer Science 276, Springer-Verlag, 20– PLAN Not. 21, 11 (Nov.), 322–330. 31. LANG,K.J.AND PEARLMUTTER, B. A. 1986. Oaklisp: HARPER,R.AND PIERCE, B. 1991. A record calculus an object-oriented Scheme with first class based on symmetric concatenation. In Pro- types. In OOPSLA’86 Conference Proceedings ceedings of the Eighteenth Annual ACM Sym- (Portland, Oregon, Sept. 26–Oct. 2). ACM posium on Principles of Programming Lan- SIGPLAN Not. 21, 11 (Nov.), 30–37. guages (Orlando, Florida, Jan. 21–23), ACM LIEBERHERR, K. J., HOLLAND,I.M.AND RIEL,A.J. Press, 131–142. 1988. Object-oriented programming: an objec- HENDLER, J. 1986. Enhancement for multiple in- tive sense of style. In OOPSLA’88 Conference heritance. In OOPSLA’86 Conference Proceed- Proceedings (San Diego, California, Sept. 25– ings (Portland, Oregon, Sept. 26–Oct. 2). 30). ACM SIGPLAN Not. 23, 11 (Nov.) 323–334. ACM SIGPLAN Not. 21, 11 (Nov.), 98–106. LIEBERHERR,K.J.AND HOLLAND, I. M. 1989. As- HARTMANN, T., JUNGCLAUS,R.AND SAAKE, G. 1992. suring good style for object-oriented program- Aggregation in a behavior oriented object ming. IEEE Softw. 6, 5 (Sept.) pp. 38–48. model. In ECOOP’92: European Conference on LIEBERMAN, H. 1986. Using prototypical objects Object-Oriented Programming (Utrecht, The to implement shared behavior in object-ori- Netherlands, June 29–July 3). Lecture Notes ented systems. In OOPSLA’86 Conference in Computer Science 615, Springer-Verlag, Proceedings (Portland, Oregon, Sept. 26–Oct. 57–77. 2). ACM SIGPLAN Not. 21, 11 (Nov.), 214– JOHNSON, R. E. 1986. Type-checking Smalltalk. 223. OOPSLA’86 Conference Proceedings (Port- LISKOV, B. H. 1987. Data abstraction and hierar- land, Oregon, Sept. 26–Oct. 2). ACM SIG- chy. In Addendum to the Proceedings of PLAN Not. 21, 11 (Nov.), 315–321. OOPSLA’87. ACM SIGPLAN Not. 23, 5 (May), KEENE, S. E. 1989. Object-Oriented Programming 1988, 17–34. is Common Lisp: A Programmer’s Guide to LOOMIS,M.E.S.,SHAH,A.V.AND RUMBAUGH,J.E. CLOS. Addison-Wesley. 1987. An object modeling technique for con- KRISTENSEN, B. B., MADSEN, O. L., MØLLER-PED- ceptual design. In ECOOP’87: European Con- ERSEN,B.AND NYGAARD, K. 1983. Abstraction ference on Object-Oriented Programming (Par- mechanisms in the Beta programming lan- is, France, June 15–17). Lecture Notes in

ACM Computing Surveys, Vol. 28, No. 3, September 1996 478 • Antero Taivalsaari

Computer Science 276, Springer-Verlag, 192– 25–27), F. H. Lochovsky and R. B. Allen, Eds. 202. ACM SIGOIS Bull. 11, 2/3 (Apr.) 205–215. MADSEN,O.L.AND MØLLER-PEDERSEN, B. 1988. PLATO. The Republic. Kustannusosakeyhtio¨ Otava, What object-oriented programming may be Keuruu, Finland. (Finnish translation, 1981). and what it does not have to be? In PORTER, H. H. III. 1992. Separating the subtype ECOOP’88: European Conference on Object- hierarchy from the inheritance of implementa- Oriented Programming (Oslo, Norway, Aug. tion. J. Object-Oriented Program. 4, 9 (Feb.) 15–17). Lecture Notes in Computer Science. 20–29. 276, Springer-Verlag, 1–20. RAJ,R.K.AND LEVY, H. M. 1989. A compositional MADSEN,O.L.AND MØLLER-PEDERSEN, B. 1989. model for software reuse. The Comput. J. 32, 4 Virtual classes: a powerful mechanism in ob- (Aug.) 312–322. ject-oriented programming. In OOPSLA’89 REDDY, U. S. 1988. Objects as closures: abstract Conference Proceedings (New Orleans, Louisi- semantics of object-oriented languages. In ana, Oct. 1–6). ACM SIGPLAN Not. 24, 10 Proceedings of the ACM Conference on Lisp (Oct.), 397–406. and Functional Programming (Snowbird, MADSEN, O. L., MAGNUSSON,B.AND MØLLER-PED- Utah, July 25–27), 289–297. ERSEN, B. 1990. Strong typing of object-ori- RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY, ented programming revisited. In OOPSLA/ F. AND LORENSEN, W. 1991. Object-Oriented ECOOP’90 Conference Proceedings (Ottawa, Modeling and Design. Prentice-Hall. Canada, Oct. 21–25). ACM SIGPLAN Not. 25, SAKKINEN, M. 1989. Disciplined inheritance. In 10 (Oct.), 140–149. ECOOP’89: Proceedings of the Third Euro- MAGNUSSON, B. 1991. Implementation of inheri- pean Conference on Object-Oriented Program- tance in Simula. Personal communication. ming (Nottingham, England, July 10–14). The British Computer Society Workshop Se- MARCOTTY,M.AND LEDGARD, H. 1987. The World of Programming Languages. Springer- ries, Cambridge University Press, 39–56. Verlag. SCHAFFERT, C., COOPER, T., BULLIS, B., KILLIAN,M. AND WILPOLT, C. 1986. An introduction to MATTOS, N. M. 1988. Abstraction concepts: the Trellis/Owl. In OOPSLA’86 Conference Pro- basis for knowledge modeling. In Proceedings ceedings (Portland, Oregon, Sept. 26–Oct. 2). of the 7th International Conference on Entity- ACM SIGPLAN Not. 21, 11 (Nov.), 9–16. Relationship Approach C. Batini, Eds. Rome, (Nov. 16–18), 331–350. SCIORE, E. 1989. Object specialization. ACM Trans. Inf. Syst. 7, 2 (April) 103–122. MEYER, B. 1988. Object-Oriented Software Con- SMITH,J.M.AND SMITH, D. C. P. 1977. Database struction. Prentice-Hall. abstractions: aggregation. Commun. ACM 20, MOON, D. A. 1986. Object-oriented programming 6 (Jun.) 405–413. with Flavors. In OOPSLA’86 Conference Pro- SMITH,J.M.AND SMITH, D. C. P. 1977. Database ceedings (Portland, Oregon, Sept. 26–Oct. 2). abstractions: aggregation and generalization. ACM SIGPLAN Not. 21, 11 (Nov.), 1–8. ACM Trans. Database Syst. 2, 2 (Jun.) 105–133. NYGAARD,K.AND DAHL, O-J. 1987. The develop- SMITH,D.C.P.AND SMITH, J. M. 1980. Conceptual ment of the Simula languages. In ACM SIG- database design. Also in Tutorial on Software PLAN History of Programming Languages Design Techniques, 4th ed., Freeman, P., Conference, Ed. (Los Angeles, California, June Wasserman, A. I. Eds. IEEE Computer Soci- 1–3), R. L. Wexelblat, ACM SIGPLAN Not. ety Press, 1983, 437–460. 13, 8 (Aug.) 245–272. SNYDER, A. 1986. Encapsulation and inheritance PALSBERG,J.AND SCHWARTZBACH, M. I. 1990. Type in object-oriented programming languages. In substitution for object-oriented programming. OOPSLA’86 Conference Proceedings, (Port- In OOPSLA/ECOOP’90 Conference Proceed- land, Oregon, Sept. 26–Oct. 2). ACM SIG- ings (Ottawa, Canada, Oct. 21–25). ACM SIG- PLAN Not. 21, 11 (Nov.), 38–45. PLAN Not. 25, 10 (Oct.), 151–159. SNYDER, A. 1986. CommonObjects: an overview. In PALSBERG,J.AND SCHWARTZBACH, M. I. 1991. ACM SIGPLAN Not. 21, 10 (Oct.), 19–28. Static typing for object-oriented program- SNYDER, A. 1991. Modeling the Cϩϩ object model: ming. Aarhus University Tech. Rep. DAIMI an application of an abstract object model. In PB-355, Denmark, June. ECOOP’91: European Conference on Object- PEDERSEN, C. H. 1989. Extending ordinary inheri- Oriented Programming (Geneva, Switzerland, tance schemes to include generalization. In July 15–19). Lecture Notes in Computer Sci- OOPSLA’89 Conference Proceedings (New Or- ence. 512, Springer-Verlag, 1–20. leans, Louisiana, Oct. 1–6). ACM SIGPLAN SOWA, J. F. 1984. Conceptual Structures: Informa- Not. 24, 10 (Oct.), 407–417. tion Processing in Mind and Machine. Addi- PERNICI, B. 1990. Object with roles. In Proceedings son-Wesley. of the ACM/IEEE Conference of Office Informa- STEIN, L. A. 1987. Delegation is inheritance. In tion Systems (Cambridge, Massachusetts, Apr. OOPSLA’87 Conference Proceedings (Orlando,

ACM Computing Surveys, Vol. 28, No. 3, September 1996 On the Notion of Inheritance • 479

Florida, Oct. 4–8). ACM SIGPLAN Not. 22, ject-oriented programming. ACM OOPS Mes- 12 (Dec.), 138–146. senger 1, 1 (Aug.) 7–87. STEIN, L. A., LIEBERMAN,H.AND UNGAR, D. 1988. A WEGNER,P.AND SHRIVER, B. Eds. 1986. Object- shared view of sharing: the treaty of Orlando. oriented programming workshop (Yorktown In Object-Oriented Concepts, Applications and Heights, New York, June 9–13). ACM SIG- Databases, W. Kim and F. Lochowsky, Eds. PLAN Not. 21, 10 (Oct.). Addison-Wesley, 31–48. WEGNER,P.AND ZDONIK, S. B. 1988. Inheritance as STEIN, L. A. 1989. Towards a unified method of an incremental modification mechanism or sharing in object-oriented programming. In what Like is and isn’t like. In ECOOP’88: Workshop on Inheritance Hierarchies in European Conference on Object-Oriented Pro- Knowledge Representation and Programming gramming (Oslo, Norway, Aug. 15–17). Lec- (Viareggio, Italy, Feb. 6–8). ture Notes in Computer Sci. 276, Springer- TAIVALSAARI, A. 1993. On the notion of object. J. Verlag, 55–77. Syst. Softw. 21, 1 (Apr.) 3–16. WILKES, W. 1988. Instance inheritance mecha- TAIVALSAARI, A. 1993. Object-oriented program- nisms for object-oriented databases. In Ad- ming with modes. J. Object-Oriented Pro- vances in Object-Oriented Databased Systems, gram. 6, 3 (Jun.) 25–32. 2nd International Workshop on Object-Ori- TAIVALSAARI, A. 1993. A critical view of inheritance ented Database Systems, (Bad Munster am and reusability in object-oriented programming. Stein-Ebernburg, Germany, Sept. 27–30), Ph.D. thesis, Jyva¨skyla¨ Studies in Computer K. R. Dittrich, Ed. Lecture Notes in Computer Science, Economics and Statistics 23, Univ. of Science 334, Springer-Verlag, 274–279. Jyva¨skyla¨, Finland, Dec. 276 pages. WIRTH, N. 1971. Program development by step- UNGAR,D.AND SMITH, R. B. 1987. Self: the power of simplicity. In OOPSLA’87 Conference Pro- wise refinement. Commun. ACM 14, 4 (Apr.) ceedings (Orlando, Florida, Oct. 4–8). ACM 221–227. SIGPLAN Not. 22, 12 (Dec.), 227–241. WIRTH, N. 1985. Programming in Modula-2. 3rd WEGNER, P. 1987. The object-oriented classifica- Ed. Springer-Verlag. tion paradigm. In Research Directions in Ob- ZDONIK, S. B. 1986. Why properties are objects, or ject-Oriented Programming. B. Shriver and P. some refinements of “is-a.” In Proceedings of Wegner, Eds. The MIT Press, 479–560. ACM/IEEE Fall Joint Computer Conference, WEGNER, P. 1990. Concepts and paradigms of ob- (Nov.) 41–47.

Received April 1994; revised September 1995; accepted January 1996

ACM Computing Surveys, Vol. 28, No. 3, September 1996