on the notion of inheritance - citeseer

On the Notion of InheritanceANTERO TAIVALSAARI

Nokia Research Center

One of the most intriguing—and at the same time most problematic—notions inobject-oriented programming is inheritance. Inheritance is commonly regarded asthe feature that distinguishes object-oriented programming from other modernprogramming paradigms, but researchers rarely agree on its meaning and usage.Yet inheritance is often hailed as a solution to many problems hampering softwaredevelopment, 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 itsusage, surveying its varieties, and presenting a simple taxonomy of mechanismsthat 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]: LanguageClassifications 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, programminglanguages

1. INTRODUCTION

A characteristic feature of object-ori-ented programming is inheritance. In-heritance is often regarded as the fea-ture that distinguishes object-orientedprogramming from other modern pro-gramming paradigms, and many of thealleged benefits of object-oriented pro-gramming, such as improved conceptualmodeling and reusability, are largelyaccredited to it. Despite its central rolein current object-oriented systems, in-heritance is still quite a controversialmechanism, and researchers tend to dis-agree on its meaning and usage. The

only currently well-developed andwidely accepted area seems to be thetheory of inheritance in terms of denota-tional semantics [Cook 1989a; Cook andPalsberg 1989; Reddy 1988].Despite the fact that much effort has

been targeted on research into inheri-tance in the past years, it seems thatinheritance is still often inadequatelyunderstood. Many studies of inheritanceconcentrate only on one specific view-point, such as type theory or conceptualmodeling, and mostly ignore the otherpossible viewpoints. Depending on theviewpoint, inheritance is regarded ei-ther as a structuring or modeling mech-

Author’s address: Nokia Research Center, P.O. Box 45, 00211 Helsinki; Finland; email: [email protected] to make digital /hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute tolists, 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

anism for reasoning about programs, ora mechanism for code sharing and re-use. It seems that a more general, com-prehensive view of inheritance is stillmissing. The main motivation for thisarticle was the desire to reach a morethorough understanding of inheritancefrom different viewpoints.This article provides a comprehensive

introduction to inheritance, startingfrom its history and conceptual back-ground, examining its intended and ac-tual usage, and discussing its essence inlight of the current knowledge. Further-more, the varieties of inheritance areanalyzed, and a simple taxonomy of in-heritance mechanisms is presented.This article is a continuation to an ear-lier article on object-oriented program-ming [Taivalsaari 1993a], and part of alarger study of inheritance, publishedas the author’s doctoral thesis [Taival-saari 1993c].

2. INHERITANCE

If I have seen a little farther than others, it isbecause I have stood on the shoulders of giants.

—ISAAC NEWTON

2.1 Definitions

In general, to inherit is to receive prop-erties or characteristics of another, nor-mally as a result of some special rela-tionship between the giver and thereceiver [Danforth and Tomlinson1988]. This broad definition of inheri-tance comes from the usage of the termin the real world, and at the first con-sideration it seems to have very little todo with computers. Nevertheless, in thecontext of programming, inheritancewas introduced as early as in the end ofthe 1960s as a central feature of theprogramming language Simula [Dahl etal. 1968]. However, Simula’s inheri-tance mechanism was originally knownby a different name, concatenation[Dahl et al. 1972, pp. 202–204; Nygaardand Dahl 1978], and the intuitivelymore appealing term inheritance wasinvented some years later. Well-known

currently used synonyms for inheri-tance in object-oriented systems aresubclassing, derivation (in C11) andprefixing (in Simula and Beta); in somepapers the term subtyping is also usedin the same meaning [Halbert andO’Brien 1987], although more commonlythat term is reserved for another pur-pose, as will be discussed in Section2.2.2.The basic idea of inheritance is sim-

ple. Inheritance allows new object defi-nitions to be based upon existing ones;when a new kind of an object class is tobe defined, only those properties thatdiffer from the properties of the speci-fied existing classes need to be declaredexplicitly, while the other properties areautomatically extracted from the exist-ing classes and included in the newclass. Thus, inheritance is a facility fordifferential, or incremental program de-velopment. Formally, inheritance can becharacterized as follows [Bracha andCook 1990; Cook 1989a; Wegner andZdonik 1988]:

R 5 P % DR.

In this maxim, R denotes a newlydefined object or class, P denotes theproperties inherited from an existingobject or class, DR denotes the incre-mentally added new properties that dif-ferentiate R from P (the delta part), andQ denotes an operation to somehowcombine DR with the properties of P. Asa result of this combination, R will con-tain all the properties of P, except thatthe incremental modification part DRmay introduce properties that overlapwith those of P so as to redefine ordefeat (cancel) certain properties of P;thus, R may not always be fully compat-ible with P. Compatibility issues will bediscussed in Section 2.2.2.There are certain terms and notions

pertaining to inheritance that will beused throughout the article. For in-stance, in the maxim above, P is knownas R’s parent or immediate ancestor; inclass-based systems the correspondingterm is superclass. Similarly, R is P’s

On the Notion of Inheritance • 439


child, immediate descendant, or inclass-based systems its subclass. Inher-itance relationships are transitive, sothat a parent or superclass may be achild or subclass of another object orclass. This implies that in addition toincrementally defined properties, an ob-ject will contain all the properties of itsparents, parents’ parents and so on. Theterms ancestor and descendant are usedin the obvious manner to denote theimmediate and nonimmediate parentsand children of a class.Most modern object-oriented systems

allow inheritance from several parentsat the same time. Such inheritance isknown as multiple inheritance, as op-posed to single inheritance discussedabove. As multiple inheritance offersconsiderably more possibilities for in-cremental modification than single in-heritance, a generally accepted view isthat a modern object-oriented languageshould support it, despite the fact thatmultiple inheritance also introducesmany conceptual and technical intrica-cies. Issues pertaining to multiple in-heritance will be discussed briefly in thefollowing section. For different defini-tions of inheritance, refer to Cardelli[1984]; Cook [1989a]; Wegner [1987];Wegner and Zdonik [1988].As an example of inheritance, con-

sider the following pseudocode defini-tion (Figure 1). In the example, twoclasses, Window and TitleWindow, aredefined. Class Window defines one vari-able, frame, and two operations (meth-ods) drawFrame and drawContents.Class TitleWindow inherits class Win-

dow and adds a new variable called titleplus a method that redefines framedrawing. The actual implementation ofthe methods is elided.In its basic form, inheritance can be

characterized formally as record combi-nation [Bracha and Lindstrom 1992;Cardelli 1984; Cook 1989a]. An object ora class that inherits the properties ofanother is viewed as a record which isotherwise similar to its parent, butwhich has been extended with some ad-ditional properties. This record combi-nation can take place in several differ-ent ways, however. For instance, inclass-based object-oriented systems (seeSection 3.1) the properties of an objectare typically located physically in differ-ent places, and this tends to make theanalysis more complicated. Further-more, other issues such as early bindingand encapsulation also encumber theanalysis of inheritance. In general, in-heritance is not an independent lan-guage feature, but it usually operates intight interaction with other languagemechanisms.

2.2 Conceptual View of Inheritance

To attain knowledge, add things every day; toobtain wisdom, remove things every day.

—LAO-TZU, Tao Te Ching

A programming language is a notationand, as such, serves to record and assistthe development of human thought in aparticular direction. For a notation to beeffective, it must carry a mental load forthe user and must have, among other

Figure 1. A simple example of inheritance.

440 • Antero Taivalsaari


properties, economy and the ability tosubordinate detail [Marcotty andLedgard 1991]. By economy it is meantthat a wide range of programs can beexpressed using a relatively small vo-cabulary and simple grammatical rules.An important goal in achieving this isthe orthogonality of language con-structs. In other words, the languageshould provide no more than one way ofexpressing any action in the language,and each construct should be backed upby solid conceptual and practical rea-sons.In order to motivate the use of inher-

itance in modern programming lan-guages, let us now examine the relation-ship of object-oriented programmingand conceptual modeling.

2.2.1 Object-Oriented Programmingand Conceptual Modeling

This structure of concepts is formally called ahierarchy and since ancient times has been abasic structure for all Western knowledge.

—ROBERT M. PIRSIG, Zen and the Art of MotorcycleMaintenance

Q: What’s big and gray, has a trunk, and lives inthe trees?

A: An elephant. I lied about the trees.

—R. J. BRACHMAN

Object-oriented programming origi-nated from Simula, a programming lan-guage that was initially targeted for thesimulation of real-world phenomena.Simulation is a task that requires agreat deal of conceptual modeling skills,and therefore right from the beginningthe developers of Simula emphasizedthe importance of a close correspon-dence between the program and prob-lem domain. As noted in Madsen et al.[1990], the primary motivation leadingto the introduction of the class conceptin Simula, for example, was to modelthe concepts in the application domain.Similarly, the inheritance mechanismwas initially introduced to representcertain kinds of modeling relationships,namely conceptual specialization [Mad-sen et al. 1990]. Let us now take a look

at the basic conceptual modeling rela-tionships in order to elucidate the roleof inheritance as a modeling mecha-nism.Generally speaking, conceptual mod-

eling can be defined as the process oforganizing our knowledge of an applica-tion domain into hierarchical rankingsor orderings of abstractions, in order toobtain a better understanding of thephenomena in concern. The principlesaccording to which this process takesplace are usually referred to as the ab-straction principles, abstraction mecha-nisms or abstraction concepts [Borgidaet al. 1984; Mattos 1988]. One of theoften mentioned benefits of object-ori-ented programming is that unlike othermodern programming paradigms, it pro-vides direct support for each of the mostimportant abstraction principles: (1)classification/instantiation, (2) aggrega-tion/decomposition, (3) generalization/specialization and (4) grouping/individ-ualization.Classification, which is usually con-

sidered the most important abstractionprinciple, is grouping like things to-gether into classes or categories overwhich uniform conditions hold [Borgidaet al. 1984]. Ideally, classes shouldshare at least one such characteristicthat the members of other classes do nothave. Classification is an intensionalabstraction principle that ought to bebased ideally on such properties of sub-stances that do not change in the courseof time. The reverse operation of classi-fication is instantiation, or exemplifica-tion [Knudsen and Madsen 1988]. In-stantiation produces instances, entitieswhich fulfill the intensional descriptionof their class. Collectively the instancesof a class form the extension of thatclass. Most object-oriented languagesprovide support for classification andinstantiation by allowing the construc-tion of classes and instances. In proto-type-based object-oriented systems (Sec-tion 3.1) there are no classes, but theeffect of instantiation can be simulatedby copying concrete objects. For a more



extensive discussion on the notions ofintension and extension, refer to Sowa[1984, pp. 10–11].The second main abstraction principle

is aggregation. By aggregation we referto the principle of treating collections ofconcepts as single higher-level concepts:aggregates [Borgida 1984; Smith andSmith 1977a]. Aggregation describesthings in terms of parts and wholes. Apart is a part by virtue of being includedin a larger whole. A part can also be-come a whole in itself, which can thenbe split into further parts. Therefore,aggregation hierarchies are sometimesalso referred to as part-whole hierar-chies. The reverse operation of aggrega-tion is decomposition, which yields theindividual components of an aggregate.Object-oriented languages typically sup-port aggregation/decomposition by al-lowing the use of objects as variables inother objects. Variables can be used tohold other objects in order to constructmore complex part-whole hierarchies.In some papers the term composition isused as a synonym for aggregation.The third major abstraction principle,

generalization, refers to the construc-tion of concepts that cover a number ofmore special concepts sharing some sim-ilarities [Knudsen and Madsen 1988;Smith and Smith 1977b]. On the basisof one or more given classes, generaliza-tion produces the description of a moregeneral class that captures the common-alities but suppresses some of the de-tailed differences in descriptions of thegiven classes [Borgida et al. 1984]. Theconverse operation of generalization isspecialization. A concept Cs can be re-garded as a specialization of anotherconcept C if all phenomena belonging tothe extension of the specialized conceptCs also belong to the extension of C[Pedersen 1989]. This implies that Cand Cs are otherwise similar, but Csmay also possess some additional, morespecific properties. Generalization andspecialization complement classificationin that they allow classes to be de-scribed naturally in terms of other

classes [Mattos 1988]. In particular,specialization—allowing new conceptsto be derived from less specific classes—seems intuitively as the natural high-level counterpart of inheritance, andtherefore it has traditionally been as-sumed that inheritance and specializa-tion are simply different views of thesame thing. Although at the first glancethis correspondence seems natural andaesthetically pleasant, recently it hasbeen observed that the relationship be-tween inheritance and conceptual spe-cialization can be confusing. This issuewill be discussed in more detail in thenext section.The fourth, perhaps the least obvious

main abstraction principle is grouping,also known as association, partitioningor cover aggregation [Brodie 1983; Mat-tos 1988]. Frequently in conceptualmodeling it becomes necessary to groupobjects together not because they havethe same properties (classification), butbecause it is important to describe prop-erties of a group of objects as a whole[Loomis et al. 1987; Mattos 1988].Grouping addresses this need by allow-ing the representation of possibly non-homogeneous collections of things re-lated by their extensional rather thanby their intensional properties. Beingbased on extensional properties, group-ing bears some resemblance to the settheory of mathematics [Mattos 1988].Object-oriented programming supportsgrouping by allowing the definition ofarbitrary collection classes such as lists,sets, bags and dictionaries. The oppositeof grouping is individualization, whichyields individual members of a collec-tion; the term individualization is, how-ever, not very well-established.The abstraction principles have been

illustrated in Figure 2, which gives anexample of each principle applied to thesame application domain, namely Car.Furthermore, the list below summarizesthe main characteristics of each princi-ple (adapted from Smith and Smith[1980]).



—Classification suppresses details ofinstances and emphasizes propertiesof a class as a whole.

—Generalization suppresses the differ-ences between categories and empha-sizes common properties.

—Aggregation suppresses details ofcomponents and emphasizes details ofthe relationship as a whole.

—Grouping suppresses details of agroup of objects and emphasizes thegrouping of those objects together.

For further information on abstractionprinciples, the reader is referred toBorgida [1984]; Knudsen [1988]; Loomiset al. [1987]; Madsen and Møller-Ped-ersen [1988] and Mattos [1988].

2.2.2 Inheritance, Subtyping and Spe-cialization

The differentiae of genera which are different andnot subordinate one to the other are themselvesdifferent in kind. For example, animal and knowl-edge: footed, winged, aquatic, two-footed, are dif-ferentiae of animal, but none of these is a differ-entia of knowledge; one sort of knowledge does notdiffer from another by being two-footed.

—ARISTOTLE, Categories §3

The classical view of inheritance in ob-ject-oriented programming is that it is ahierarchical structuring mechanism in-tended for conceptual specialization. In-deed, language constructs for support-ing generalization/specialization are

Figure 2. Abstraction principles.



often mentioned as the main character-istic of a programming language sup-porting object-orientation [Madsen andMøller-Pedersen 1988]. Correspond-ingly, object-oriented programming hassometimes been characterized as “pro-gramming with taxonomically organizeddata” [Cardelli 1984].Recently it has however been ob-

served that the correspondence betweeninheritance and specialization is actu-ally much more intricate than has pre-viously been assumed [America 1987;Wegner and Zdonik 1988; Zdonik 1986].Most of the problems in this respectarise from the fact that object-orientedsystems do not typically provide anyguarantees in that inheritance really isused for conceptual specialization. Forinstance, the redefined operations in asubclass do not usually have to bear anysemantic relationship to the replacedoperations in the superclass; the onlysemantic tie is that they share the samenames [Zdonik 1986]. In general, if in-heritance is implemented in the conven-tional fashion, allowing unlimited addi-tion, redefinition and cancellation ofproperties in descendants, there is vir-tually nothing to ensure that the con-ceptual correspondence between par-ents and their children really prevails.Consequently, abstractions built usinginheritance rarely are true conceptualspecializations of their parents.Some researchers have tried to guar-

antee the conceptual correspondence be-tween parents and children by estab-lishing certain compatibility rules. Forinstance, Wegner has identified four dif-ferent levels of compatibility betweenclasses and subclasses [Wegner 1990;Wegner and Zdonik 1988]. The weakestof these, cancellation, allows the opera-tions of the class to be freely redefinedand even cancelled (removed) in a sub-class. The second level, name compati-bility allows the operations to be rede-fined, but requires the subclass topreserve the same set of names (i.e., noproperties may be removed). The thirdlevel, signature compatibility requiresfull syntactic (interface) compatibility

between classes and their subclasses.The fourth level, behavior compatibilityassumes full behavioral compatibilitybetween classes and their subclasses.This implies that subclasses may notchange the behavior of their super-classes in any radical way. The firstthree forms of compatibility, beingbased on mere syntactic aspects of classdefinitions, are relatively easy to guar-antee, and inheritance mechanismsbased on them are generally referred toas nonstrict inheritance [Wegner 1987;Wegner and Zdonik 1988]. Ensuring fullbehavior compatibility, however, turnsout to be a much more difficult task.The term strict inheritance is often usedto refer to behaviorally compatibleforms of inheritance [Wegner 1987;Wegner and Zdonik 1988].While strict inheritance at the first

consideration seems to be the most de-sirable form of inheritance, there areseveral other reasonable ways to useinheritance that necessitate nonstrictinheritance. These alternative uses ofinheritance will be discussed in detail inthe next section. In fact, it has beenargued that strict inheritance, i.e., theuse of inheritance for conceptual spe-cialization, is of limited utility in theevolutionary development of complexsystems [Wegner 1987]. After all, strictinheritance restricts the use of inheri-tance to the refinement of existingabstractions only, and prohibits the in-cremental modification of those abstrac-tions in more creative ways. When us-ing strict inheritance only, the additionof anything truly new to the system hasto be accomplished by constructingthose abstractions from scratch. In gen-eral, it seems that nonstrict inheritancecan increase the expressive power ofobject-oriented systems. However, atthe same time it decreases structuralclarity because so much less can be in-ferred about the properties of descen-dants [Wegner 1987].Another problematic issue in equat-

ing inheritance with specialization ismultiple inheritance. An often cited con-troversial example of multiple inheri-



tance can be found in a book by Meyer[1988]. In his book, Meyer defines aclass Fixed_Stack by inheriting two pre-viously defined classes Stack and Array[Meyer 1988, pp. 241–242]. This ishighly questionable because inheritingthese classes implies that Fixed_Stack,in addition to being a specialization ofStack, would also be a specialization ofArray. From the conceptual viewpoint,this is incorrect since many operationson arrays, such as the indexed elementaccess operations, are not generally ap-plicable to stacks. The correct solutionin this case would be to inherit classStack only, and use class Array as acomponent. Similar abuses of multipleinheritance are surprisingly common inthe literature. In general, since multipleinheritance always results in a combi-nation of existing abstractions, it tendsto be difficult to regard it as a form ofconceptual specialization. Rather, mul-tiple inheritance seems to have more incommon with aggregation. As aptly ex-pressed by Alan Snyder in a panel dis-cussion at OOPSLA’87: “multiple inher-itance is good but there is no good wayto do it.” For further information onusing multiple inheritance refer to Du-cournau and Habib [1987], Knudsen[1988] and Snyder [1991].Based on the observations above it

should be obvious that equating inheri-tance with conceptual specializationposes several problems. Generallyspeaking, there seems to be a discrep-ancy between inheritance as a languagemechanism and inheritance as a facilityfor conceptual modeling. These tworoles of inheritance can be characterizedas follows [Korson and McGregor 1990]:

(1) As part of the high-level programdesign phase, inheritance serves asa means of modeling generalization/specialization relationships.

(2) In the low-level implementationphase, inheritance supports the re-use of existing classes as the basisfor the definition of new classes.

One of the first researchers to empha-size this distinction was Brachman[1983] who investigated the role of is-arelationships in semantic networks.Brachman suggested that inheritanceshould be treated only as an implemen-tational issue that bears no direct corre-spondence to conceptual modeling.Later papers to study the relationshipof inheritance and specialization in thecontext of object-oriented programmingare America [1987; 1991], Cook et al.[1990], Palsberg and Schwatzbach[1991], Porter [1992] and Raj and Levy[1989]. A common argument in thesepapers is that in object-oriented sys-tems a clear distinction ought to bemade between two important concepts:inheritance and subtyping. Inheritanceis a more low-level mechanism by whichobjects or classes can share behaviorand data. Subtyping, on the other hand,expresses conceptual specialization[America 1991]. Following this dichot-omy, inheritance is a mechanism that issuited but not necessarily limited tospecialization (see Figure 3). In thiscontext inheritance is often also re-ferred to more specifically as implemen-tation inheritance, representation inher-itance or in class-based systemssubclassing. Commonly used synonymsfor subtyping are specification inheri-tance or interface inheritance [America1987, 1991; Madsen et al. 1990]. Somepapers also use the terms syntactic andsemantic inheritance to distinguish be-tween inheritance of implementationand specification, respectively [Hart-mann et al. 1992].It is widely argued that using inheri-

tance for specialization is both theoreti-cally and practically valuable, while us-ing it for mere implementation purposesis likely to cause difficulties and reflectspoor understanding of the purpose ofinheritance. Therefore, following theAristotlean tradition of dividing thingsinto essential and accidental, the use ofinheritance for specialization is oftencharacterized as essential use of inheri-tance, whereas the other uses are con-sidered more or less accidental or inci-



dental [Sakkinen 1989]. However, asalready mentioned above and as will bediscussed further in next section, thereare other uses of inheritance beyondspecialization that can be consideredwell-justified and thus essential, too.Although the reasons for distinguish-

ing between inheritance and subtypingare widely recognized and accepted, sofar this distinction has been incorpo-rated only in a few programming lan-guages. Some languages making thedistinction are POOL-I [America 1991]and Typed Smalltalk [Graver and John-son 1990; Johnson 1986]. In these lan-guages subtyping serves as a higher-level relation between types, whereasinheritance operates at the level ofclasses. In most other (strongly-typed)object-oriented languages—includingC11, Eiffel, Trellis/Owl [Schaffert et al.1986] and Simula—types are, however,equated with classes, and inheritanceis basically restricted to satisfy therequirements of subtyping [Cook et al.1990]. As observed in several papers[Cook 1989b; Palsberg and Schwartzbach1991], this can lead to problems in typechecking. These type checking issues are,however, beyond the scope of this article.A drawback of the suggested separa-

tion between inheritance and subtypingis the extra complexity that it places onthe implementation and use of lan-guages supporting such separation.Furthermore, it has been argued thatnot even this distinction is enough ifone wants to be specific about the or-thogonality of language constructs. Sim-ilarly as there exists a distinction be-tween inheritance and subtyping, thereis a significant difference between sub-typing and specialization. LaLonde[1989] and LaLonde and Pugh [1991]have proposed the following definitionsfor the three concepts:

—Subclassing is an implementationmechanism for sharing code and rep-resentation.

—Subtyping is a substitutability rela-tionship: an instance of a subtype canstand in for an instance of its super-type.

—Is-a is a conceptual specialization re-lationship: it describes one kind ofobject as a special kind of another.

Subclassing, subtyping, and special-ization are all important for differentreasons. Subclassing supports reusabil-ity for the class library implementor:

Figure 3. Inheritance versus subtyping (traditional view).



new kinds of classes can be defined byleveraging off existing ones. Subtypingsupports reusability for the class libraryuser: to get maximum reusability, weneed to know which classes can be sub-stituted with which other classes. Spe-cialization (is-a) relationships, in turn,are important for understanding thelogical relationships between the con-cepts; in this sense, specialization isimportant for the class library designer.Figure 4 illustrates the differences be-tween subclassing, subtyping, and spe-cialization [LaLonde and Pugh 1991].Each of the concepts in Figure 4 can be

refined further. For instance, as observedby Brachman [1983; 1985], there are sev-eral kinds of is-a relationships. Varietiesof subtyping have been examined by Weg-ner [1987], who distinguishes the follow-ing “subtypes” of subtyping:

—Subset subtyping. Int[1..10] is a sub-set subtype of Int.

—Isomorphic copy subtyping. Int is anisomorphic copy subtype of Real.

—Object-oriented subtyping. Student isan object-oriented subtype of Person.

The varieties of inheritance and sub-classing will be examined in the follow-ing subsections.

2.2.3 Use of Inheritance in Practice

Like the ski resort full of girls hunting for hus-bands and husbands hunting for girls the situa-tion is not as symmetrical as it might seem.

—ALAN MACKAY

Inheritance is a language mechanismthat allows new object definitions to bebased on existing ones. A new class inher-its the properties of its parents, and mayintroduce new properties that extend,modify or defeat its inherited properties.In general, most object-oriented lan-guages allow the inherited properties tobe reimplemented, renamed, removed,duplicated, have their visibility changed,or undergo almost any other kind oftransformation as they are mapped fromparents to descendants. Therefore, it isapparent that inheritance can be used forpurposes that go beyond specialization. Infact, the use of inheritance for conceptualspecialization seems to be an ideal that israrely realized. Most commercially avail-able class libraries, such as the standardclasses of Smalltalk-80 or commercialC11 class libraries, are permeated withexamples of using inheritance in otherways. This section examines those uses ofinheritance that are common in real ob-ject-oriented systems, but which do not

Figure 4. Subclassing, subtyping, and specialization.



obey the semantic requirements of con-ceptual specialization.

Inheritance for implementation refersto situations in which inheritance isused not because the abstractions to beinherited are ideal from the conceptualpoint of view, but simply because theyhappen to contain appropriate proper-ties for the new abstraction that is un-der construction. In implementation in-heritance, theoretical and conceptualissues such as behavior compatibilityare ignored, and pragmatic reasonssuch as potential savings in coding ef-fort, storage space or execution speedare emphasized instead. As obvious, us-ing inheritance for mere implementa-tion reasons is often questionable, andit has been criticized in the literature[America 1987; Sakkinen 1989]. Some ofthe most apparent variations of imple-mentation inheritance are (adaptedfrom Rumbaugh et al. [1991, p. 64]):

—cancellation,—optimization, and—convenience.

In cancellation, the descendant re-stricts the inherited behavior by explic-itly making certain inherited propertiesunavailable, or by tightening the pa-rameter type requirements. Cancella-tions are common in the Smalltalk-80collection class hierarchy that will bediscussed below. In optimization, thedescendant takes advantage of somespecific implementation information toimprove the code for its operations. Forexample, a superclass Set could have anoperation to find the maximum elementimplemented as a sequential search; thesubclass SortedSet could provide a moreefficient implementation for the sameoperation since the elements are al-ready sorted. In implementation inheri-tance for convenience, the new class ismade a subclass of the existing classsimply because the existing class seemsto provide what is desired.The archetypical example of the use

of implementation inheritance is theCollection class hierarchy of Small-

talk-80 [Goldberg and Robson 1989, pp.144–169; Graver and Johnson 1990; La-Londe 1989; LaLonde et al. 1986; Weg-ner 1990]. The Collection class hierar-chy consists of more than 20 classesthat represent various kinds of con-tainer objects such as Sets, Bags (setsthat allow duplicate elements), Dictio-naries (mappings from keys to values),and Strings. Many of these classes havebeen made subclasses of others simplybecause the superclass happens to con-veniently provide the right functional-ity. For example, class Dictionary im-plements a keyed lookup table as a hashtable of ^key, value& pairs. The hashtable implementation is inherited fromclass Set (which in turn is a subclass ofCollection), but applications using Setswould behave quite differently if givenDictionaries instead. In other words,class Dictionary is behaviorally incom-patible with its superclass. Besides con-venience, the Collection class hierarchyprovides examples of cancellations andoptimizations as well. For instance,since Dictionary elements can only beremoved by their key values, class Dic-tionary overrides the remove:ifAbsentmethod inherited from class Set with anerror message method. Similarly, theiteration method do: is redefined in al-most every collection class to optimize itfor each particular kind of abstraction.Despite its idiosyncrasies, the Collec-tion class hierarchy of Smalltalk doeshave its advantages. Generally it seemsthat implementing the same functional-ity in a conceptually more elegant fash-ion would necessitate a more complexand more memory-consuming class hier-archy. Cook has argued to the contrary,however, and has presented an alterna-tive Collection class hierarchy based onthe conceptual relationships of theclasses [Cook 1992].

Inheritance for combination refers tosituations in which inheritance is usedfor combining existing abstractions withmultiple inheritance [Halbert andO’Brien 1987]. As illustrated by theFixed_Stack example discussed in Sec-



tion 2.2.2, such use of inheritance iserror-prone, and in many cases it wouldbe appropriate to use single inheritanceand aggregation instead. Nevertheless,two subforms of combination inheri-tance can be identified. First, multipleinheritance is often used for combiningabstractions of equal importance. Theclassical example of such use of multipleinheritance is to inherit two classes,Teacher and Student, to form a classTeachingAssistant [Halbert and O’Brien1987; Sciore 1989]. In practice the com-bination of conceptually equal abstrac-tions using multiple inheritance can bequite laborious, however, because suchabstractions tend to contain a largenumber of overlapping properties thathave to be dealt with in the subclass[Chambers et al. 1991]; sometimes thismay necessitate considerable modifica-tions. In many cases such situationscould also be expressed more naturallyusing roles [Pernici 1990]. For instance,from the conceptual viewpoint, Teacherand Student are not really proper sub-classes of Person, but they shouldrather be seen as different roles thatpersons are capable of playing at differ-ent times. The second form of inheri-tance for combination is mixin-based in-heritance, or mixin inheritance [Brachaand Cook 1990; Hendler 1986], whichhas recently received considerable at-tention. Mixin inheritance originatedfrom the programming languages Fla-vors [Moon 1986] and Oaklisp [Langand Pearlmutter 1986], and has subse-quently been utilized in the CommonLisp Object System (CLOS) [DeMichieland Gabriel 1987; Keene 1989]. Mixininheritance will be discussed in moredetail later in Section 3.7.

Inheritance for inclusion. One alter-native use of inheritance is also inheri-tance for inclusion. Many class-basedobject-oriented languages (e.g., Small-talk) do not provide a separate modulemechanism, and thus classes are some-times needed for simulating modules orfunction libraries. For instance, to cre-ate a library of trigonometric functions

in an object-oriented language withouta module mechanism, the only viableway is to place those functions in aseparate class. This library class canthen be used in two different ways. Thefirst possibility is to “instantiate” thelibrary, which has the negative conse-quence that the functions will have tobe accessed indirectly via an interven-ing variable. The second way is to useinheritance to simulate the importmechanism of many abstract data type(ADT) languages such as Modula-2[Wirth 1985]. Using the library as asuperclass, the functions in the librarywill be included in the scope of thesubclass and can thus be referred todirectly without extra effort. This ispractical, but is yet another example ofusing inheritance for other reasons thanconceptual specialization.

Other uses of inheritance. In addi-tion to the above-mentioned uses of in-heritance, some researchers have iden-tified several rarer forms of inheritance.One such example is inheritance forgeneralization that can be seen as theopposite of inheritance for specializa-tion [Halbert and O’Brien 1987; Ped-ersen 1989]. Like specialization, inheri-tance for generalization is based onconceptual reasons, but the actual di-rection of conceptual relationships hasbeen reversed. In other words, ratherthan specializing the behavior of itsparent, a descendant is designed as ageneralization of its parent. Inheritancefor generalization has been investigatedin detail by Pedersen [1989], who con-siders such use of inheritance valuablewhen changes to the existing classifica-tion hierarchy are needed and whenthose changes should be accomplishedincrementally rather than by modifyingthe existing inheritance hierarchy. An-other advantage of generalization isthat in some situations it may be easierto implement abstractions as generali-zations of more special concepts thanvice versa [Halbert and O’Brien 1987;Pedersen 1989]. For example, if a sys-tem already incorporates a deque ab-



straction, then the implementation ofstack by generalization is easier thanby constructing it from more generalabstractions [Snyder 1986a].In conclusion, there is no single answer

as to what constitutes proper use of in-heritance. Although conceptual special-ization was originally regarded as theonly legitimate reason for using inheri-tance, in practice inheritance is com-monly used for other quite reasonablepurposes. Consequently, a major themein the object-oriented programming re-search in the past years has been theclarification of the role of inheritance.Despite these efforts, researchers stillhave differing opinions on inheritance,and a lot of work in this area remains tobe done.

2.3 The Essence of Inheritance

On the basis of the preceding discussionit appears that the analogy between in-heritance and conceptual specializationis a lot weaker than has often beenclaimed. In order to reach a better un-derstanding of what the essence of in-heritance in object-oriented program-ming really is, let us now set theconceptual modeling viewpoint aside fora while, and approach the issue from amore pragmatic viewpoint. The sectionstarts by recognizing certain inherentproblems in traditional programmingmethodologies and by showing how in-heritance can address these problems. Amore theoretical discussion of the es-sence of inheritance will then follow.

2.3.1 Inheritance as an IncrementalModification Mechanism

Ours is a world of things—but of changing thingsnot quiescent ones.

—MARIO BUNGE, The Furniture of the World

There are six kinds of change: generation, de-struction, increase, diminution, alteration, changeof place.

—ARISTOTLE, Categories §14

A well-known fact in software devel-opment is that if a piece of software is

useful, it will have to be changed.Therefore, one of the most importantqualities of software is malleability, ormodifiability; the easier the softwaresystem is to change, the more likely it isthat it will fulfill the requirements itwas built to satisfy, and the more easilyit will be able to keep up with the evolv-ing needs of the users. Traditional pro-gramming methodologies do not takethis evolutionary nature of softwareinto account very well. The principles ofabstract data type (ADT) programming,such as locality of information, modu-larity and representation independence[Liskov 1987], provide some help in thisrespect, but are unable to solve some ofthe most central issues.One of the main problems plaguing

software development is that programmodification, in the traditional fashion,is a process of destructive or radicalchange [Cook 1989a; Cook and Palsberg1989]. In many situations, even smallmodifications to some parts of the sys-tem will have widespread effects on theother parts. The larger the software sys-tem is, the greater is the likelihood ofundesired, inadvertent side-effects. Yetmany of the changes in software sys-tems do not really necessitate destruc-tive modification. If the modifications,replacements, or removals of existingparts of the program were explicitlyavoided, and an incremental program-ming style were adopted, these unfore-seen effects could be avoided.To properly understand the problems

with destructive modification, let usconsider an example in which we arebuilding a simple graphical windowingsystem. In Figure 5, we define a classWindow whose instances are assumedto be windows on the screen. To avoidextra verbosity and complexity, only asmall subset of the variables and opera-tions needed in implementing a realwindow system have been included. It isassumed that methods drawFrame anddrawContents display the frame and thecontents of a window on the screen atthe location specified by the variablerect. Method refresh invokes both these



methods in order to update both theframe and the contents. Since the exam-ple will be used to illustrate furtheraspects of inheritance in the end of thissection, references to methods draw-Frame and drawContents have been de-noted using a special pseudovariableself. At this point these self-referencescan simply be ignored.Suppose we would later like to modify

our window system to support windowsthat are capable of displaying a title(name) on their frame. In conventionalADT systems this can be achieved intwo basic ways. The first way is to editthe source code of the existing classWindow to support both plain windowsand windows with a title. This could beaccomplished by adding a new variableto hold the title of the window, andanother variable to store information ofwhether the current window is a plainone or one with a title. Additionally, acase statement should be added tomethod drawFrame to determinewhether or not the title should beprinted on the frame.The second way to achieve the same

effect is to copy the source code of theexisting Window class and edit the copyto form a completely new TitleWindowclass—this approach can be called the“copy-and-modify” scheme. Neither ofthese approaches is really satisfactory.In a large system direct modification ofan existing component is likely to causeinconsistencies with the other compo-nents that happen to refer to the prop-erties of the modified component. Thecopy-and-modify scheme, on the otherhand, is uneconomical, because usually

the changes to the existing componentsare relatively small in proportion to theoverall size of the component. Further-more, textual copying loses the relation-ship between the original and copiedcomponent, and this is likely to causemaintenance problems later on. In gen-eral, there are two arguments againsttampering with existing source code[Krueger 1992].

—Editing source code forces the soft-ware developer to work at a low levelof abstraction. The effort required tounderstand and modify the low-leveldetails of a component offsets a signif-icant amount of the effort saved inreusing the component.

—Editing source code may invalidatethe correctness of the original compo-nent. This eliminates the ability toamortize validation and verificationcosts over the life of a reusable com-ponent.

Inheritance addresses the above men-tioned problems by promoting incre-mental definition. By adding new prop-erties, a new class can extend, modifyand defeat the properties inherited fromits parents, but the original class stillremains the same. However, note thatthe avoidance of destructive changes it-self is not enough. So as to avoid unnec-essary redefinitions, some extra linguis-tic support is needed. Consider thedefinition in Figure 6.The class definition in Figure 6 is an

attempt to define a new class TitleWin-dow as an extension of the previouslydefined class Window. Since class Win-

Figure 5. Class Window.



dow implements the basic functionalityof windows, it seems apparent that inorder to create windows with a title ontheir frame, the only thing that needs tobe redefined is the previously definedoperation drawFrame. However, a prob-lem with this approach is that after theredefinition of drawFrame, all those op-erations in superclass Window that hap-pen to refer to the original operationdrawFrame, such as refresh, are invalid.When applied to instances of TitleWin-dow, method refresh will still invoke theoriginal method drawFrame of classWindow, thus producing windows with-out a title on their frame.In general, it is common for class def-

initions to contain a large number ofoperations that refer to the other opera-tions in the same definition. These in-terdependencies between classes makeincremental modification problematic; ifone operation is redefined in a descen-dant, all the other operations referringto that operation will also have to beredefined. This is inconvenient andagainst the idea of incremental modifi-cation. For this reason, an additionallanguage mechanism, late binding, isneeded. Late binding allows referencesto the properties of objects to be post-poned until the program is actually run,thus making operations polymorphic,i.e., able to take on different meaningsat different times. By virtue of latebinding, references to other propertiesfrom within an operation do not have tobe statically fixed, but may invoke dif-ferent properties depending on the con-text from which the operation is actu-ally invoked. This dynamic context isdetermined by self-reference, a pseudo-variable that denotes the object whoseoperation is currently being executed.

In the window system example above,for instance, the use of late-bound self-reference causes the behavior of opera-tion refresh to vary dynamically depend-ing on which kind of a window it iscurrently acting upon, thereby ensuringthat the correct drawFrame operationcan be invoked.What do we learn from all this? First,

it is apparent that many modificationsneeded in software systems could beperformed incrementally, yet conven-tional systems enforce these modifica-tions to be carried out in a destructivemanner. Second, late binding is a pre-requisite for implementing a systemthat allows true incremental modifica-tion. Without late binding, there is noassurance that newly defined compo-nents will work correctly when inher-ited operations are applied to them. Ingeneral, inheritance can be defined asfollows (adapted from Cook [1989a] andCook and Palsberg [1989]):

Inheritance is an incremental modifica-tion mechanism in the presence of alate-bound self-reference.

A detailed description of the semanticsof late binding and self-reference will begiven in the next section.

2.3.2 Late Binding and Self-Reference

To thine own self be true.

—WILLIAM SHAKESPEARE, Hamlet

Inheritance is an incremental modifica-tion mechanism. By virtue of inheri-tance, a new object class can extenditself by internalizing properties of an-cestors as though they were its own[Wegner 1987]. Late binding, as impliedabove, allows this internalization to beperformed in a manner that minimizes

Figure 6. Class TitleWindow.



the need for physical code duplication,by letting the same operations invokedifferent properties depending on thecontext from which these operations areinvoked, thereby promoting sharing ofcode. This section takes a more theoret-ical look at how incremental modifica-tion is actually achieved, and gives ageneral description of the semantics oflate-bound message sending. Since weare not yet focusing on any particularmodel of inheritance, the descriptionwill be kept independent of implementa-tion aspects.Theoretically, inheritance can be

characterized as the operation that de-rives new abstractions from previouslydefined ones, denoted formally R 5 P QDR, or in the case of multiple inheri-tance: R 5 P1 Q P2 Q . . . Q Pn Q DR.When applied transitively, the opera-tion results in abstraction hierarchiesthat take the form of tree (in the case ofsingle inheritance), or more generally:directed acyclic graph (DAG; see Amer-ica [1987] and Knudsen [1988]). Eachnode in an inheritance DAG representsa collection of properties that has beenincrementally added on top of the inher-ited properties at some particular level,corresponding to a delta part in some“R 5 P Q DR” declaration.Note that although in object-oriented

systems inheritance is typically possibleonly between classes, there is usuallyan isomorphic correspondence betweenclasses and their instances, so that in-stances can also be viewed as inheri-

tance DAGs if so desired. The mappingbetween classes and their instancesmay not always be totally one-to-one,however, because repeated inheritance(e.g., a class having two superclassesthat have a common superclass; alsoknown as fork-join inheritance [Sakki-nen 1989], or diamond inheritance[Bracha 1992, pp. 24–26]) may causesome instance variables to be dupli-cated. Bear in mind that an essentialrestriction on all inheritance hierar-chies is that they may not contain cy-cles. This restriction is obvious as itwould be nonsensical for abstractions toinherit their own properties.If objects are viewed as directed acy-

clic graphs, the semantics of inheritancecan be described quite easily and inde-pendently of any particular model ofinheritance. Whenever a late-boundmessage is sent to an object, the follow-ing kind of an algorithm will take con-trol. The algorithm is illustrated in Fig-ure 7 (adapted from Cook [1989a] andCook and Palsberg [1989]). Parts of thefigure will be discussed also in the nextsubsection.

(1) First, self-reference is set to refer tothe receiver of the message. Previ-ous value of self-reference is savedso that it can be restored later. InFigure 7, this phase is called SEND.

(2) The given message selector is thenmatched against the properties ofthe receiver by traversing its inher-itance DAG node by node. The ac-

Figure 7. Semantics of message passing with late binding.



tual traversal order depends on theform of inheritance being used (Sec-tion 3.3). In Figure 7, this phase iscalled LOOKUP.

(3) If a matching property is found insome node, the matching property isinvoked, e.g., using a normal proce-dure call mechanism. In Figure 7,this phase is termed CALL. Afterexecution, the previous value of self-reference is restored.

(4) In case no matching property can befound in the whole DAG, a bindingerror will be raised. In Figure 7, thisphase is called ERROR.

As a result of successful late binding,the matching operation of the object willbe invoked. During the execution of theoperation, the self-reference will remaindenoting the root of the current inheri-tance DAG, so that subsequent messagesends via the self-reference from withinthat operation can access the otherproperties of the object. By virtue of latebinding, operations inherited from par-ents can invoke such properties thatwere not necessarily even implementedat the time when the parent was de-fined.Note that in actual implementations

of object-oriented languages, the abovedescribed algorithm is usually replacedwith much more efficient strategies.Simple inline caching techniques[Deutsh and Schiffman 1984], for in-stance, eliminate the need to performthe actual lookup in 95 percent of thesituations. Various optimization tech-niques have been surveyed in Driesen etal. [1995].To the programmer, the self-reference

typically appears in the form of a spe-cial pseudovariable, self, that can beused explicitly to inform the systemthat late binding via self-reference isrequested. At the language level, self istreated as a free variable whose textualoccurrences in a program are bound to aparticular object only at the time theyare executed. By the term pseudovari-able it is implied that self is system-

maintained and cannot be modified bythe programmer.In different languages different

names for the self-reference are used.Smalltalk and its derivatives use self,whereas in Simula, Beta [Kristensen etal. 1983; Madsen and Møller-Pedersen1989] and C11 the corresponding lan-guage construct is known as this. Eiffelprovides a pseudovariable current forthe same purpose [Meyer 1988, p. 79and 177]. In some object-oriented lan-guages self-references are implicit. InEiffel, for instance, current is usuallyelided, and thus late-bound operationinvocations look syntactically identicalto ordinary procedure calls in conven-tional programming languages. TheC11 programmer may explicitly decidewhether or not to use this in his mem-ber function calls.

2.3.3 Accessing Overridden Proper-ties. Besides self, object-oriented lan-guages typically provide other pseudo-variables that contribute to theincremental definition of programs. Themost common of these is super [Gold-berg and Robson 1989, pp. 63–66] thatis used for accessing those inheritedproperties that have been redefined insubclasses. When an operation sends amessage via super, the lookup is startedfrom the immediate parent of the nodepossessing that operation. This is differ-ent from normal message lookup inwhich the lookup is always started fromthe node denoted by the self-reference.When using super, the self-reference isleft untouched, so that subsequent mes-sages via self from the redefined opera-tions will be able to access the morerecently defined properties.In order to illustrate the behavior of

super, let us take the class TitleWindowdefined in Section 2.3.1 into consider-ation again. In that example we rede-fined the operation drawFrame in orderto construct windows with a title ontheir frame. In such a situation it wouldapparently be a great help if we couldsomehow utilize the previously defineddrawFrame operation of superclass



Window. However, since the purpose ofclass TitleWindow is primarily to de-scribe the title extension, it shouldknow as little as possible about the ac-tual frame drawing process. In order toavoid code duplication, the new draw-Frame operation for TitleWindowshould apparently first invoke the ear-lier drawFrame operation, thus drawingthe plain border, then calculate the cor-rect position for the title, and print thetitle on the frame. This is exactly whatcan be accomplished using the super-reference (see Figure 8). Without super,the whole frame printing algorithmwould have to be reimplemented in thesubclass. Thus, the super-reference isan invaluable tool for reducing the needfor code reimplementation and contrib-uting to incremental modification.Several variations of super-reference

exist. Whereas super is characteristic oflanguages modeled after Smalltalk, inCLOS the corresponding language con-struct is known as call-next-method[Keene 1989, p. 233]. Unlike super,CLOS’s call-next-method does not re-quire any message selector as parame-ter, but uses the previous selector nameby default. In this sense CLOS’s call-next-method is analogous to Beta’s innerconstruct [Kristensen et al. 1983], al-though otherwise Beta’s inheritancescheme is radically different (see Sec-tion 3.3). C11 gives the programmerthe ability to access redefined proper-ties by using superclass names as qual-ifiers [Ellis and Stroustrup 1990, p.390]. Eiffel does not provide any explicitsuper-reference, but allows the same ef-fect to be simulated by renaming theinherited properties in the subclass

[Meyer 1988, pp. 246–250]. Some lan-guages, such as Simula and Deltatalk[Borning and O’Shea 1987] do not pro-vide any facilities for accessing rede-fined operations, and this may limit in-cremental modification in manysituations. In Self [Ungar and Smith1987], the super-reference was origi-nally called super, but later renamed asresend [Chambers et al. 1991].In general, late binding, self-reference

and super-reference are salient ele-ments of all inheritance mechanisms.Late binding and self-reference allowthe programmer to perform “surgery”which can change object behavior with-out physically reaching inside any ob-ject. Super-reference supplements thesefacilities by allowing access to redefinedproperties, thereby reducing the needfor code duplication. When used prop-erly, together these facilities allow theproperties of objects to be reused with-out any textual copying or editing,which is a major advantage over otherprogramming styles and techniques. Inthis sense, inheritance is a truly noveland fundamental mechanism for con-structing programs [Cook 1989a].

2.3.4 Inheritance as a SpecificationalStructuring tool

Inside every large program there is a small pro-gram trying to get out.

—C.A.R. HOARE

Incremental modification is not a pana-cea. Not all modifications to programscan be performed incrementally. Never-theless, many of the problems in con-ventional software development meth-

Figure 8. Class TitleWindow using super-reference.



odologies can be alleviated considerablyusing incremental modification. One ad-ditional benefit of inheritance in thisrespect is that it enables the construc-tion of partially, or incompletely imple-mented abstractions. By partially imple-mented abstractions we refer toabstractions whose definitions havepurposely been left incomplete, andwhose properties may thus refer to suchcomponents or properties that have noteven been implemented yet; late bind-ing is obviously needed for this. Ab-stractions of this kind are sometimesextremely useful, because they canserve as specifications or contracts uponwhich the concrete implementations canbe based, thus facilitating the conver-gence of analysis, design, and imple-mentation. Such abstractions often havea communicative role, allowing the de-signers to agree upon the interfaces ofthe abstractions before the actual im-plementation efforts are started. In gen-eral, these ideas are intimately relatedto Wirth’s notion of successive, or step-wise refinement [Wirth 1971].In class-based object-oriented sys-

tems, partial implementation is usuallysupported in the form of abstractclasses. An abstract class is a class thatspecifies a message interface, but doesnot fully implement it. Such a class iswritten with the expectation that itssubclasses will add to its structure andbehavior, usually by completing the im-plementation of its incomplete opera-tions. Since abstract classes are imple-mented only partially, by convention noinstances are created from them. Infact, in some papers abstract classes aredefined as classes which even cannot beinstantiated; many systems, such asSmalltalk-80, do not guarantee this,however. Since abstract classes serveonly to provide inheritable functional-ity, they are often also referred to asabstract superclasses [Bracha 1990].Other frequently used synonyms are ba-sic classes in CLOS terminology [Keene1989, p. 224], deferred classes in Eiffelterminology [Meyer 1988, pp. 234–240],abstract superpatterns in Beta terminol-

ogy [Madsen and Møller-Pedersen1989], and partial types [Halbert andO’Brien 1987].Representative examples of abstract

classes in object-oriented systems areclasses Object and Collection in Small-talk. Smalltalk’s class Object is an ab-stract superclass that defines the gen-eral properties of all objects in theSmalltalk system [Goldberg and Robson1989, pp. 94–103]. Instantiation of classObject would, however, make littlesense since Object exhibits no other be-havior than these general operations.Similarly, class Collection defines thegeneral message protocol for variouscollection classes such as dictionaries,sets, arrays and strings. Many opera-tions in class Collection, such as theiteration method do:, have deliberatelybeen left unimplemented, however, andare to be added by the subclasses.In systems utilizing mixin inheritance

(see Section 3.7), partial implementa-tions are used for another purpose. Mix-ins are small, noninstantiatable por-tions of behavior that are used solely foradding properties to other classes.Mixin classes do not define any generalframework or serve as specifications ofsome larger abstraction hierarchy.Rather, they just describe reusablepieces of functionality that can be at-tached to other classes using multipleinheritance. Therefore, as opposed toordinary abstract superclasses, mixinclasses are sometimes referred to as ab-stract subclasses [Bracha and Cook1990].In general, we can distinguish two

additional forms of inheritance: inheri-tance from complete implementationsand inheritance from partial implemen-tations [Halbert and O’Brien 1987].Both forms rely on performing modifica-tions in an incremental fashion and arethus subcategories of the more generalnotion of incremental modification. In-heritance from complete implementa-tions allows the reuse and refinement ofexisting complete abstractions, while in-heritance from partial implementationsserves as a specificational structuring



tool, enabling the successive refinementof programs from abstract specificationstowards successively more concrete im-plementations. Some researchers haveargued that inheritance from completeimplementations is harmful and shouldbe avoided [Lieberherr et al. 1988;Lieberherr and Holland 1989].Note that in a way, abstract classes

have a dual role. On the one hand, theyhave a conceptual role, and serve asspecification or design tools in the abovedescribed manner, their presence beingmotivated by the conceptual analysis ofthe problem domain. On the other hand,abstract classes also have a more prag-matic role: to serve as hooks for improv-ing reusability. These two roles are notnecessarily coincident; in order to makea class hierarchy as reusable as possi-ble, it is often essential to split theproblem domain into smaller classes(and have more abstract classes) thanwould otherwise be necessary from theconceptual viewpoint. This is becausethe smallest unit of reuse in most ob-ject-oriented systems is the class. Mixininheritance discussed later in Section3.7 is a good example of the potentialdiscrepancy between reuse and model-ing.

3. VARIATIONS OF INHERITANCE

Understanding depends on expectations based onfamiliarity with previous implementations.

—MARY SHAW

What we’ve got is freedom of choice. What wewant is freedom from choice.

—From a song by a new-wave band, Devo

Object-oriented language design spaceis not a dichotomy, and these lan-guages cannot be categorized into com-pletely clear-cut, orthogonal subclasses.Rather, they seem to be more like aresult of “mixin inheritance”: the samebasic themes and patterns are repeatedover and over again in slightly differentforms and variations. This similaritybetween models is intriguing, and itsparks the desire to explore the possible

common constituents further. This sec-tion undertakes a detailed analysis ofthe variations of inheritance mecha-nisms in object-oriented programmingsystems, aiming at new insights as towhat the possible common constituentsof different inheritance models are. Atthe same time, some further conceptsand notions will be introduced. Finally,a simple taxonomy of the basic mecha-nisms and issues underlying the seem-ingly divergent forms of inheritance willbe presented.

3.1 Class Inheritance Versus PrototypeInheritance

Class is a state of grace that few people have.

—DOROTHY CULLMAN

Prototype: the first or primary of anything; theoriginal (thing or person) of which another is acopy, imitation, representation, or derivation, or isrequired to conform; a pattern, model, standard,exemplar, archetype.

—Oxford English Dictionary VIII, p. 1512

Object-oriented systems are usuallybuilt around classes. Classes are de-scriptions of objects capable of servingas templates or “cookie-cutters” fromwhich instances, the actual objects de-scribed by classes, can be created. Thiscreation process is typically known asinstantiation. In broad terms, a classrepresents a generic concept, or a “reci-pe,” while an instance represents anindividual. A class holds the similaritiesamong a group of objects, dictating thestructure and behavior of its instances,whereas instances hold the local datarepresenting the state of the object.Class-based systems are quite class-

centric. To add a new kind of an objectto the system, a class describing theproperties of that object type must bedefined first. Similarly, inheritance canonly take place between classes,whereas instances are completely “ster-ile”, i.e., incapable of serving as parents.Therefore, the model is commonly re-ferred to as class inheritance [Stein etal. 1988; Wegner 1987, 1990].



An interesting alternative for tradi-tional class inheritance is prototype in-heritance, or object inheritance [Blas-chek 1994; Borning 1986; Dony et al.1992; Liebermann 1986; LaLonde et al.1986; Stein et al. 1988; Stein 1987; Un-gar and Smith 1987]. As opposed toclass-based systems, in prototype-basedsystems there are no classes. Rather,new object types are formed directly byconstructing concrete, full-fledged ob-jects, which are referred to as prototypesor exemplars. A prototype can bethought of as a standard example in-stance, which represents the default be-havior for some concept. Prototype-based systems provide no classes, andtherefore in these systems there is nonotion of instantiation either. The effectof instantiation, the ability to createmultiple objects of similar kind, isachieved by cloning (copying) existingobjects instead. In addition, objects inprototype-based systems are usually in-dividually modifiable. By virtue of theindividuality of objects, prototype-basedsystems support incremental modifica-tion at the level of individual objects, asopposed to class-based systems in whichtypically only groupwise (class-level)modification is possible.From the philosophical viewpoint the

distinction between class-based andprototype-based systems reflects thelong-lasting philosophical dispute con-cerning the representation of abstrac-tions. Plato viewed forms—stable, im-mutable descriptions of things—ashaving an existence more real than in-stances of those abstractions in the realworld [Plato 1981, Books 6 and 7]. Ob-ject-oriented languages like Smalltalkand Simula are Platonic in their explicituse of classes to represent similarityamong collections of objects. Prototype-based systems represent another way ofviewing the world, in which one choosesnot to categorize things, but rather toexploit their alikeness. A typical argu-ment in favor of the prototype-basedapproach is that people seem to be a lotbetter at dealing with specific examplesfirst, then generalizing from them, than

they are at absorbing general abstractprinciples first and later applying themin particular cases [Lieberman 1986].There are many variations of proto-

type-based systems [Dony et al. 1992;Taivalsaari 1993c]. Roughly speaking,prototype-based object-oriented lan-guages can be divided into two broadcategories according to how incrementalmodification is supported in them: dele-gation-based and copying-based. In del-egation-based languages, there is a spe-cial delegation mechanism that providesthe incremental modification capability[Lieberman 1986]. In delegation-basedlanguages, when an object receives amessage it does not understand, the ob-ject will delegate the message to thoseobjects that have been designated as its“parents.” Parent objects will then try tocarry out the message on the delegatingobject’s behalf. During the delegationprocess, the self-reference will remainpointing to the original receiver, allow-ing late-bound properties in parents tooperate in the context of the originalreceiver. Delegation will be discussed inmore detail in the next section. The bestexample of a delegation-based object-oriented language is Self [Ungar andSmith 1987], a Smalltalk-like languagethat has become the yardstick againstwhich other prototype-based object-ori-ented languages are measured.Borning [1986] has shown that a pro-

totype-based language does not neces-sarily have to support delegation in or-der to be a full-fledged object-orientedlanguage. Borning demonstrated thatby utilizing cloning (copying) and thepossibility to dynamically add new prop-erties to objects in the presence of theregular late-binding message sendingmechanism, it is possible to capture theessence of inheritance—incrementalmodification—in a prototype-based lan-guage even without delegation. Unlesssupplanted with some additional mech-anisms and implementation techniques,this model has some problems, however.In particular, as a result of extensiveuse of copying, memory consumptioncan be excessively high. Also, groupwise



modification of objects is more tediousthan in delegation-based systems due toabsence of common parent objects orany explicit inheritance hierarchy. Ex-amples of prototype-based object-ori-ented languages built along the lines ofBorning’s model are Omega [Blaschek1991] and Kevo [Taivalsaari 1993c].Prototype-based object-oriented lan-guages have been discussed in detail ina book by Blaschek [1994].

3.2 Delegation Versus Concatenation

Inheritance is acquisition of propertiesfrom past generations. More practically,inheritance is a relationship betweenobjects that guarantees that a descen-dant has at least the properties that itsparents have. By incrementally adding,redefining or defeating properties, thedescendant can become differentiatedfrom its parents. At the level of objectinterfaces this implies that the recordrepresenting the descendant must con-tain at least those identifiers that itsparents have. In addition, the descen-dant can introduce new identifiers thatare either distinct or overlapping. Anincrementally added identifier is said tobe distinct if no other identifiers withthe same name exist in the same inher-itance DAG. Otherwise, the identifier isoverlapping. In general, from the view-point of interface management, inheri-tance is simply a combination operationR 5 P Q DR on record structures P 5[. . .] and DR 5 [. . .] with possibly over-lapping identifiers (see Wegner andZdonik [1988]). This combination opera-tion must be able to relate the interface(name space) of descendant R to theinterface of parent P.Within computer memory there are

only two ways to express direct relation-ships between things: references or con-tiguity. Based on this observation, twoelementary strategies for implementinginheritance can be distinguished: dele-gation and concatenation. Delegation isa form of inheritance that implementsinterface combination by sharing the in-terface of the parent—in other words,

using references. Concatenation, on theother hand, achieves the same effect bycopying the interface of the parent intothe interface of the descendant—as aresult of this, the descendant’s interfacewill be contiguous. As an example ofdelegation and concatenation, considerthe simple example below. Let us as-sume that we have the following kind ofobject aPen defined in our system withtwo variables x and y and a methodcalled draw, defined using simple recordnotation.

aPen:-[VAR x, VAR y, METHOD draw];

Suppose that we now want to defineanother object aTurtle that inherits theproperties of aPen and adds a new vari-able heading and a method forward. Ifwe accomplish this using delegation, theinterface of the descendant will be asfollows:

aTurtle:-[PARENT p :-aPen, VAR heading,METHOD forward];

On the other hand, using concatenationthe interface of the resulting object willbe contiguous, as illustrated below:

aTurtle:-[VAR x, VAR y, METHOD draw,VAR heading, METHOD forward];

In both cases the basic result is thesame: the descendant will be able torespond to messages corresponding tothe inherited identifiers in addition tothe incrementally added ones. However,the way in which message sending ishandled in these approaches is differ-ent. In delegation, those messages thatare not accepted by the most specializedpart of the object must be delegated(forwarded) to parents. In concatena-tion, the interface of every object is self-contained, and thus no forwarding isneeded. Since the term delegation im-plies shared responsibility for the com-pletion of a task, it would be misleadingto use that term to denote also thelatter form of inheritance. Delegationand concatenation have been illustratedin Figure 9.Note that the difference between del-

egation and concatenation is indepen-



dent of the question of whether the sys-tem is based on classes or prototypes;delegation and concatenation canequally underlie both models. The maindifference is that in class-based systemsdelegation or concatenation takes placebetween classes, whereas in prototype-based systems the same occurs betweenindividual objects. In fact, although theterm concatenation is not widely used inthe current literature of object-orientedprogramming, there are good historicalreasons for its use. The concept of pre-fixing in Simula [Dahl et al. 1968],which later evolved into the modernconcept of inheritance, was originallydefined in terms of textual concatena-tion of program blocks [Cook and Pals-berg 1989] (see Dahl et al. [1972, pp.202–204, Nygaard and Dahl 1987]).Even in the current implementations ofSimula and its descendant Beta [Kris-tensen et al. 1983] the interfaces (to bemore specific: the virtual operationsearch tables) of classes and their sub-classes are self-contained and indepen-dent of each other [Madsen and Møller-Pedersen 1988; Magnusson 1991]. Onthe other hand, as shown by Stein[1987], the way that inheritance be-tween classes is achieved in Smalltalk

is analogous to the delegation approachadopted in prototype-based languagessuch as Self. In both approaches unre-solved messages will always be for-warded to separate constructs; in Small-talk this separate construct is asuperclass, and in Self it is a parentobject.In general, delegation and concatena-

tion are distinct strategies for imple-menting inheritance, both of whichcan equally underlie class-based andprototype-based systems. Simula andits descendant Beta are examples oflanguages which implement class inher-itance by concatenation. Smalltalk, onthe other hand, implements class inher-itance by delegation. Self is the bestexample of a language that implementsprototype inheritance by delegation. Thecopying-based approach discussed inSection 3.1 represents prototype inheri-tance by concatenation. Thus, althoughit has sometimes been claimed that del-egation is a mechanism that can bethought of as underlying all inheritancemechanisms [Stein 1987], this is notreally the case. One of the few papers inwhich a similar distinction between dif-ferent kinds of object-oriented systemshas been made is, Snyder [1991],

Figure 9. Delegation versus concatenation.



wherein Snyder distinguishes mono-lithic objects and multiobjects. Snyder’snotion of monolithic objects is roughlyanalogous to our notion of concatena-tion, whereas his multiobjects representthe use of delegation (see also Sakkinen[1989]).The main differences between delega-

tion and concatenation have been gath-ered into Table I. Most of the differ-ences between the approaches pertainto the treatment of inheritance graphs(DAGs). Delegation preserves inheri-tance DAGs without modifications, butconcatenation requires DAGs to be flat-tened out into contiguous name spaces.This flattening implicitly prevents haz-ardous cycles in inheritance DAGs, butat the same time it causes some impor-tant differences in the usage of thesemodels. The notions of life-time sharingand creation-time sharing mentioned inthe table will be defined later in Section3.8.Delegation and concatenation both

have certain advantages over eachother. For instance, owing to dependentinterfaces, delegation enables flexiblepropagation of change: any change toparents will be automatically reflectedto descendants. This can be extremelyuseful at times, allowing a large groupof objects to be modified simply bychanging a common parent. On theother hand, thanks to self-contained in-terfaces, concatenation supports inde-pendent modification of object inter-faces, making possible renaming andselective inheritance (Section 3.6). As forefficiency, delegation is generally morespace-efficient due to extensive use ofsharing, but concatenation is generallymore time-efficient since the absence of

sharing makes it easier to optimize themethod lookup more aggressively.

3.3 Direction and Completion of MessageLookup

Perfection is achieved only on the point of col-lapse.

—C.N. PARKINSON

In Section 2.3.2 we described the generalmessage sending algorithm that can beseen as underlying all inheritance mecha-nisms. The algorithm consisted of fourelements—SEND, LOOKUP, CALL andERROR—that were intentionally definedsomewhat vaguely. In particular, theLOOKUP part of the algorithm simplystated that as part of message matchingthe inheritance DAG will be traversednode by node. We did not, however, spec-ify what the actual traversal order is.Neither did we completely specify whenthis lookup will eventually end. For ex-ample, if the DAG contains several over-lapping identifiers, it is unclear whichone of these properties should be invoked,or should they all become invoked. In thelatter case it would be important to spec-ify also the exact order in which all theseoverlapping properties are to be executed.Moreover, in case of multiple inheritancethe overlapping of identifiers is often in-advertent, and the undesired identifiername collisions should somehow be takeninto account. These issues will be ad-dressed in this and the next section. Notethat all these questions apply equally toclass-based and prototype-based systems,regardless of whether they are based ondelegation or concatenation.In most contemporary object-oriented

systems the message lookup proceeds

Table 1. Delegation versus concatenation.



from the most recently defined (descen-dant) parts of objects towards the leastrecently defined parts (parents). For ex-ample, the behavior of message lookupin Smalltalk has been described infor-mally as follows [Goldberg and Robson1989, p. 61]: “When a message is sent,the methods in the receiver’s class aresearched for one with a matching selec-tor. If none is found, the methods inthat class’s superclass are searchednext. The search continues up the su-perclass chain until a matching methodis found”. Thus, in Smalltalk messagelookup always has a specific direction,and will terminate as soon as the firstmatching property is found. This con-vention is used in various other object-oriented languages including C11 andEiffel, except that in many systemsmultiple inheritance makes thingssomewhat more complicated. Since thelookup is dominated by the most re-cently defined parts of objects, i.e.,those properties that have been definedat the descendant level, we call thisscheme descendant-driven inheritance.As usual, there are some interesting

variations. Beta [Kristensen et al. 1983;Madsen and Møller-Pedersen 1989], adescendant of Simula, uses a totally op-posite parent-driven lookup scheme. InBeta, property lookup is started fromthe topmost superpattern (the Betaequivalent of superclass) in the currentinheritance DAG. Beta supports singleinheritance only, so this topmost super-pattern is always unique, and the inher-itance DAG can be seen simply as alinear path from parents to descen-dants. When a message is sent to anobject (in Beta terminology: a virtualprocedure is invoked), lookup proceedsfrom the virtual procedures defined inthe topmost superpattern towards morerecently defined superpatterns of theobject until a matching procedure isfound. This matching procedure willthen be invoked in the normal manner.Since superpatterns have precedenceover their subpatterns, the Beta-stylereverse inheritance strategy ensuresthat descendants can never totally over-

ride the behavior inherited from par-ents, thereby providing additional sup-port for maintaining the behavioralcompatibilities between parents and de-scendants.The distinction between descendant-

driven and parent-driven lookupschemes is illustrated in Figure 10.Note that the parent-driven lookupscheme is not really suited to systemswith multiple inheritance, because insuch systems inheritance DAGs do notnecessarily have any single root nodefrom which the lookup could be started.Besides the differences in the direc-

tion of message lookup, the inheritancescheme of Beta deviates from main-stream object-oriented languages also inother ways. One important differencepertains to the completion or exhaustionof message lookup. In most object-ori-ented systems message lookup is termi-nated as soon as a matching propertyhas been found and executed. If theprogrammer wants to execute the over-ridden properties inherited from theparents, it is the programmer’s respon-sibility to explicitly do so by definingthe methods to explicitly call the meth-ods of their parents. Many object-ori-ented languages provide a special super-reference exactly for this purpose, asdiscussed earlier in this paper.Beta addresses the lookup exhaustion

issue differently. In Beta, the overlap-ping (“extended”) properties in subpat-terns will always be invoked automati-cally without programmer intervention.After finding and executing a matchingproperty, the lookup will be continuedimplicitly in the parent-driven lookuporder until all the corresponding prop-erties in the object have been executed.This is essentially different from main-stream object-oriented systems in whicheven one matching property will sufficeto terminate the lookup. As noted byMadsen and Møller-Pedersen, theSmalltalk-style of terminating thelookup immediately after encounteringthe first matching method is more flexi-ble, but is also a potential source oferrors since the programmer may forget



to execute the corresponding property inthe superclass [Madsen and Møller-Ped-ersen 1989].Theoretically, the direction and ex-

haustion issues are closely related torecord combination. In his thesis, Cook[1989, p. 10] suggested that a distinc-tion be made between left preferentialand right preferential record combina-tion in order to specify the precedence ofmessage lookup. However, since theterms left and right are quite impreciseand open to interpretations, the termsparent and descendant are used here inthe same meaning. In general, theoreti-cally we can make a distinction betweenfive basic inheritance (record combina-tion) schemes, as illustrated in Table II.Strict record combination refers to situ-ations in which overlapping propertynames are strictly forbidden. Asymmet-ric combination (see Harper and Pierce[1991]) refers to such schemes in whichthe lookup is limited to the first match-ing property. Composing combinationrequires all the matching properties to

be executed. In Table II, x is the prop-erty to be executed, and P and R denotethe sets of properties defined at theparent and child level, respectively. Aspecial operation o is used to denoteexecution ordering; for instance, a o bimplies that both a and b are executed,but a is invoked before b.Note that although the inheritance

scheme of Beta is radically different fromthan in most other object-oriented sys-tems, these systems are typically capableof simulating each other quite easily. InSmalltalk, for instance, Beta’s composingmessage lookup scheme can be simu-lated simply by systematically placingan explicit super-reference within everymethod. Moreover, if these super-refer-ences are always positioned in the begin-ning of each method, the lookup orderbecomes logically parent-driven, eventhough the physical search order still re-mains descendant-driven. The same tech-nique can be used in Beta which providesa special inner construct for controllingthe order of subpattern execution [Kris-

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



tensen et al. 1983; Madsen and Møller-Pedersen 1989]. The behavior of inner isanalogous to that of super-reference, butits direction is reverse. Rather than in-voking properties of superclasses, Beta’sinner construct invokes properties in sub-patterns. Thus, by placing an inner-refer-ence in the beginning of each virtual func-tion in a Beta program, the lookup orderbecomes logically descendant-driven.However, there is no easy way to simu-late asymmetric message lookups in Beta.There are also other techniques that

can be used to control the direction andexhaustion of message lookup. In partic-ular, mixin inheritance discussed inSection 3.7 allows all the inheritanceschemes listed in Table II to be simu-lated flexibly; different schemes areachieved simply by changing the orderin which base classes and mixins arecombined. For a thorough discussion onthis idea, refer to Bracha and Cook[1990]. Among the currently availableobject-oriented languages, the CLOSsystem with its special before, after andaround methods provides perhaps themost comprehensive facilities for deal-ing with the lookup direction and ex-haustion. For further information onthese aspects of CLOS, see DeMichieland Gabriel [1987] and Keene [1989, pp.11–13, and 50].

3.4 Ordered Versus Unordered Inheritance

A name is a spoken sound significant by conven-tion, without time, none of whose parts is signifi-cant in separation.

—ARISTOTLE, De Interpretatione §2

It’s useful to the people that name them, I sup-pose. If not, why do things have names at all.

—LEWIS CARROLL, Through the Looking Glass

A problematic issue pertaining to multi-ple inheritance are name collisions. Aname collision occurs when the inheri-tance DAG contains overlapping proper-ties and the property lookup algorithmis unable to decide which one of these toexecute. Not all overlapping propertiesresult in name collisions, however. Forexample, in single inheritance the over-lapping of properties is a natural resultof incremental modification: when a de-scendant redefines some of its inheritedproperties to differentiate itself from itsparent, the newly redefined propertiesnaturally overlap with the inheritedones. This form of overlapping of prop-erties poses no problems for messagelookup algorithms and is sometimescalled vertical overlapping (see Knudsen[1988]). In multiple inheritance verticaloverlapping occurs analogously whentwo properties with the same name arelocated along the same path in an inher-itance DAG. For example, in Figure 11aidentifier x in node D vertically overlapswith identifier x in its parent node A.Problems arise when overlapping of

properties is horizontal. Horizontallyoverlapping identifiers are those thatare located along distinct paths in aninheritance DAG (see property y in Fig-ure 11b), and thus horizontal overlap-ping can take place only in multipleinheritance. Generally speaking, thereare two basic approaches to dealingwith name collisions: ordered and unor-dered inheritance [Chambers et al.

Table 2. Variations of record combination for message lookup



1991]. Most Lisp-based systems such asFlavors [Moon 1986], CommonLoops[Bobrow et al. 1986] and CLOS[DeMichiel and Gabriel 1987; Keene1989] obey ordered multiple inheritanceschemes. In these systems the inheri-tance DAG is first somehow linearized,and the first matching property on thislinear path will then be executed re-gardless of the other properties with thesame name. In contrast, languages likeTrellis/Owl [Schaffert 1986], Eiffel[Meyer 1988], C11 [Ellis and Strous-trup 1990] and CommonObjects [Snyder1986b] treat inheritance DAGs withoutany relative ordering. In these lan-guages, name collisions are consideredprogramming errors, and any ambigu-ities must be resolved explicitly by theprogrammer.Note that not even horizontal overlap-

ping of properties should always betreated as a name collision. If two con-ceptually unrelated abstractions arecombined using multiple inheritance, itmay well happen that these abstrac-tions accidentally contain overlappingidentifiers [Chambers et al. 1991]. Sincethe abstractions are conceptually unre-lated, it is clear, however, that the oper-ations of these abstractions are not in-tended to access each others’ properties.For instance, in the example above, thelate-bound invocation of property y viaself-reference from node A or D shouldnot result in a name collision, although

a similar invocation from node F cer-tainly should. In order to be able to copewith these kinds of situations, some sys-tems have been augmented with quitecomplicated mechanisms and inheri-tance rules. For example, an earlier ver-sion of Self included a special senderpath tiebreaker rule for addressing thisparticular problem [Chambers et al.1991]. For further information on thetreatment of name collisions, see partic-ularly Knudsen [1988].

3.5 Dynamic Inheritance

Wood may remain ten years in the water, but itwill never become a crocodile.

—Congolese proverb

In Section 3.2 a distinction between twofundamental strategies for implement-ing inheritance—delegation and concat-enation—was made. It was concludedthat both strategies have their own ben-efits that are difficult to capture usingthe other strategy. In this section thisdiscussion is taken a bit further by dis-cussing dynamic inheritance: the abilityto change parents of objects dynami-cally at runtime [Chambers et al. 1991;Stein et al. 1988]. Despite being intu-itively a rather dangerous language fea-ture, dynamic inheritance providessome notable benefits, and therefore,although dynamic inheritance has typi-cally been available only in some proto-

Figure 11. Vertically and horizontally overlapping identifiers.



type-based systems, it has recently cap-tured the interest of many researchersof class-based systems as well.Recall from the earlier discussion that

delegation-based systems accomplishthe interface combination required byincremental modification by sharing theinterface of the parent, i.e., using refer-ences rather than copying. In class-based systems, the references betweenchildren and parents are usually main-tained by the system and are completelyinaccessible to the programmer. In con-trast, in prototype-based systems thesereferences are typically implemented asparent slots. By giving these slotsnames, and by making them assignable,we allow the parents of objects to bechanged on the fly. Consider the follow-ing object definitions:

aPEN:-[VAR x, VAR y, METHOD draw];aTurtle:-[PARENT parent:-aPen, VARheading, METHOD forward];

Assuming that the parent slot parentbehaves like an ordinary variable, wecan dynamically change the parent slotto refer to some other object. Below wedefine a new object a3dPen, supposedlyrepresenting a three-dimensional coun-terpart of aPen, and make this objectthe parent of aTurtle.

a3dPen:- [VAR x, VAR y, VAR z, METHODdraw];aTurtle.parent:- a3dPen;

After these operations, the behaviorof aTurtle is no longer the same as itwas before. The object contains an extravariable z, and the actual method drawis different than before. As apparent,dynamic inheritance can be quite dan-gerous. If the properties of the new par-ent do not comply with those needed bythe descendant, runtime binding errorswill result. Dynamic inheritance canalso have a deteriorating effect on per-formance, since the possibility to changeparents at runtime prevents certainkinds of message lookup optimizationsfrom being done [Chamber et al. 1991].The benefits of dynamic inheritance

are best described by giving an exam-

ple. In the design and implementationof programs we are often faced withthings and structures that can be indifferent states or conditions. In thiscontext we are not referring to the con-crete state of the variables of these ob-jects, such as the integer 12345 in vari-able foo, but rather to a moreconceptual or logical kind of state. Forinstance, container objects such asstacks, lists and queues can be empty,nonempty or full. In graphical user in-terfaces, windows can usually be open,closed or represented as icons. Simi-larly, application-specific objects suchas bank accounts, flight reservations, orpatient registers also exhibit manykinds of logical states. The behavior ofthe operations of objects typically variesconsiderably depending on these logicalstates. For instance, the behavior of thepop operation of a stack depends essen-tially on whether the stack containsitems or is empty; in the latter case popmust not return any value but ratherraise an error. Similarly, when a bankaccount has been frozen by the bank,the teller machine should not dispenseany money when a withdrawal is re-quested but rather swallow the card. Inconventional object-object systems,these kinds of logical states or modes, asthey are sometimes called, are hard toexpress. Usually, additional state vari-ables and control structures are needed.For instance, each of the basic windowmanipulation operations such as open,close, iconify, resize and zoom typicallyhas to contain an explicit if-statementor case-statement to determine whetherthe operation is appropriate for the win-dow in the current situation. Obviously,the diffusion of mode information andaccumulation of control structures bothtend to have a negative impact on thereadability and maintainability of code.Dynamic inheritance provides a solu-

tion to the problems with logical states.Since the behavior of objects can bechanged at runtime, not all the informa-tion about an object has to be describedin one class or prototype. Rather, byimplementing a separate set of methods



for each logical state, the behavior ofeach mode can be kept clearly apartfrom the others. Dynamic inheritance isillustrated in Figure 12 in which we seea window object with three parent ob-jects (“traits” in Self terminology[Chambers et al. 1991]) representingthe different logical states of windows(open, closed, iconified). Each of the par-ent objects implements the same basicset of methods, but the behavior of themethods is specialized to each particu-lar logical state. Initially the parent slotof the prototype is set to point to traitsOpenWindow, implying that only thoseoperations that are applicable to openwindows are available, but when thelogical state of the object changes atruntime, e.g., the window becomesclosed, the parent slot is changed corre-spondingly. Using this approach,method definitions can be kept conciseand clear, because the methods in onemode do not have to know how the othermodes behave. The number of controlstructures in programs is reduced sub-stantially.Note that dynamic inheritance is not

typically possible in class-based sys-

tems. This is mainly due to the fact thatin class-based systems classes describenot only behavioral but structural as-pects as well; if the superclass of a classwere suddenly changed at runtime, thestructure of the instance would likely beincompatible the structure specified bythe new superclass. The fact that mostclass-based systems do not support latebinding of variables makes the situationeven more problematic. Due to the ap-parent benefits of modes, however,there have been some proposals on howto add corresponding mechanisms toclass-based systems [Chambers 1993;Stein 1989; Taivalsaari 1993b]. Amongthese, Chambers’ predicate classes seemparticularly promising.

3.6 Selective Inheritance

Just as delegation enables dynamic in-heritance, concatenation gives rise tosome interesting variations of inheri-tance. For instance, the self-containednature of object interfaces in concatena-tion has the advantage of making theobject interfaces independent of eachother. This possibility is utilized in

Figure 12. Dynamic inheritance.



Eiffel, which allows the inherited prop-erties to be renamed in subclasses[Meyer 1988, pp. 246–250]. Renamingapparently requires that the inheri-tance mechanism is implemented usingconcatenation; otherwise the modifica-tion of inherited identifiers would not bepossible without affecting superclasses.Besides allowing renaming, indepen-

dent interfaces have other benefits. Inparticular, they make possible suchforms of inheritance in which not allproperties of inherited abstractionshave to be passed to descendants.Rather, the descendant can be given theexplicit possibility to decide which par-ticular properties of parents to inheritand which not. Such forms of inheri-tance are said to represent selective in-heritance [Wilkes 1988]. Selective inher-itance has been tried out in Sina/St[Aksit and Tripathi 1988], a Smalltalk-based system that dispenses withclasses and uses a two-level type con-cept with separate interfaces and imple-mentations instead. At the level of typeinterfaces, the programmer can explic-itly select which properties of objects toinherit and which not. The Kevo system[Taivalsaari 1993c] also supports selec-tive inheritance through its partial re-use mechanisms.One of the interesting theoretical as-

pects of selective inheritance is that itshows that the difference between in-heriting an abstraction (such as a classor a prototype) and using the abstrac-tion as a variable is actually very sub-tle. From the interface combinationviewpoint the only difference betweenthese is that in the former case theproperty names of the inherited compo-nent are implicitly included into theinterface of the descendant, and thusthe inherited properties can be referredto directly. In contrast, in the lattercase the properties are not included andmust be accessed indirectly via an inter-vening variable. As an example of this,consider the following example. Assumethat we have the following objects t1and t2 defined in our system. Since weare dealing with interface aspects only,

the actual method implementations andvariable values are ignored.

t1 :- [METHOD m1, VAR v1];t2 :- [METHOD m2, VAR v2];

Suppose that we now define two otherobjects t3 and t4 which make use of theexisting objects t1 and t2. Object t3uses t1 and t2 as its parents, whereast4 uses t1 and t2 as its variables. Notethat in this particular example t3 hasbeen implemented using delegation andt4 using reference variables, but thesituation would be analogous using con-catenation and containment.

t3 :-[PARENT p1 :- t1, PARENT p2 :- t2,METHOD m3, VAR v3];

t4 :-[VAR p1 :- t1, VAR p2 :- t2, METHODm3, VAR v3];

Basically, the only difference betweenobjects t3 and t4 pertains to how theirproperties can be accessed. In case of t3(t1 and t2 as parents), the properties oft1 and t2 can be accessed directly with-out having to mention the interveningidentifiers p1 and p2. In case of t4 (t1and t2 as variables), the interveningidentifiers along the access path toproperties m1, v1, m2 and v2 must bementioned explicitly. For example, thefollowing expressions

t3.m1;t3.v2;

are legal, whereas the correspondingmessages to t4 would lead to bindingerrors. Thus, for t4 the interveningidentifiers p1 and p2 must be used asshown below.

t4.p1.m1;t4.p2.v2;

Note that in the presence of selectiveinheritance the distinction between par-ents and variables becomes blurred. Se-lective inheritance allows only a subset ofthe identifiers of parents to be broughtinto the interface of the descendant, andhence the degree of “parentness” and“variableness” can be varied. In particu-lar, if a language provides a mechanismby using which any uniquely named prop-erty within an object can be accessed di-



rectly without having to specify the fullpath to it, then from the viewpoint ofinterface management the distinction be-tween variables and parents will vanishaltogether. This idea is utilized in Sina/Stwhere multiple inheritance is achievedsimply by declaring multiple variables atthe interface of a type and making theproperties of these variables directly ac-cessible by means of an appropriate pred-icate [Aksit and Tripathi 1988]. Ofcourse, in most object-oriented languagesencapsulation (information hiding)changes the picture to some extent, sincenot all variables or methods may be ac-cessible to outside clients due to beingdeclared private.The use of selective inheritance can

lead to some conceptual and technicalproblems. In particular, incautiousomission of inherited properties canproduce objects whose interfaces are in-complete, and that do not possess allthe properties to which their operationsneed access. Therefore, additionalmechanisms may have to be introducedto guarantee the completeness of ob-jects. For further information on selec-tive inheritance, refer to Aksit and Tri-pathi [1988], Cook [1989a] and Wilkes[1988].

3.7 Mixin Inheritance

Mixin inheritance is a certain way ofusing inheritance that has receivedquite a lot of attention in the literatureof object-oriented programming [Bracha1992; Bracha and Cook 1990; Hendler1986]. This is not surprising, consider-ing that mixin inheritance has certainimportant theoretical and pragmaticbenefits. On the theoretical side, mixininheritance has been proven to be capa-ble of capturing the functionality of sev-eral other forms of inheritance [Brachaand Cook 1990]. Therefore, mixin inher-itance is sometimes regarded as a more“elementary” form of inheritance thatcan provide help in understanding theother forms. On the pragmatic side,mixin inheritance is beneficial becauseit can considerably improve the reus-ability of program components.The basic idea of mixin inheritance is

simple. Unlike in ordinary inheritance,in which the modification (delta) partsin class definitions are embedded di-rectly in the new definitions (see Figure13a), in mixin inheritance separatemixin classes are created to hold themodifications [Bracha and Cook 1990;Hendler 1986]. A mixin class is syntac-tically identical to a normal class, but

Figure 13. Ordinary inheritance versus mixin inheritance.



its intent is different. Such a class iscreated solely to be used for addingproperties to other classes—one nevercreates an instance of a mixin. Newconcrete classes, such as class R in Fig-ure 13b, are constructed by combiningprimary parent classes (class P in Fig-ure 13b) with secondary mixin classes(R_Mixin) using multiple inheritance.Since mixin classes do not have su-

perclasses and are not therefore struc-turally bound to any specific place inthe inheritance hierarchy, the samemodifications (delta parts) can be re-peatedly used (inherited) without hav-ing to rewrite or copy their contentsmanually when similar modificationsare needed in other places [Bracha andCook 1990]. This enhances reusabilityby allowing the same functionality to beflexibly added to various components.Using single inheritance in a similarsituation, considerable code duplicationwould result because the same pieces ofcode would have to be repeatedly writ-ten in several classes. Ordinary multi-ple inheritance would usually suffice tosolve the problem, too. However, ordi-nary multiple inheritance is prone tocause difficulties if the same classes be-come inherited two or more times alongdifferent inheritance paths (e.g., classhas two superclasses that have a com-mon superclass). As already mentionedearlier in the article, this problem iscommonly referred to as repeated inher-itance [Meyer 1988, pp. 274–279], fork-join inheritance [Sakkinen 1989], or dia-mond inheritance [Bracha 1992, pp.24–26].Note that in mixin inheritance multi-

ple inheritance is used strictly for com-binatory purposes. Provided that themixin classes are implemented cor-rectly, no additional manual “gluing” isneeded when base classes and mixinsare inherited (combined). In practicethis requires that the methods of mixinclasses are implemented in such a waythat they are open to extensions, andremember to invoke the correspondingmethods in their surrounding environ-

ment (see, e.g., Bracha and Cook[1990]).Mixin inheritance is not without prob-

lems. From the conceptual point of view,one of the less beneficial characteristicsof mixin inheritance is that it tends tocause confusion in the relationship ofobject-oriented programming and con-ceptual modeling by diversifying therole of classes. As apparent in Figure13b, in mixin inheritance classes areused for three distinct purposes. First,there are base classes that define thegeneral characteristics of a hierarchy ofconcepts. These classes are either con-crete instantiable classes, or abstractnoninstantiable classes that exist solelyto be refined by their subclasses. Sec-ond, there are mixin classes that serveas elementary units of reusable behav-ior. Mixin classes cannot be used inisolation but must first be combinedwith a concrete class to become func-tional; therefore, mixin classes aresometimes referred to as abstract sub-classes [Bracha and Cook 1990]. Third,mixin-based systems also have combi-nation classes that are needed for in-stantiating concrete instances with thedesired functionality.In summary, mixin inheritance can

considerably increase the reusability ofclass definitions, but at the same time itmay decrease the conceptual clarity ofthe system by requiring the same classmechanism to be used for three differ-ent purposes in a rather subtle andunintuitive way. In this sense, mixininheritance serves as a practical exam-ple of the fact that reusability and con-ceptual modeling are opposite goals: inorder to obtain maximum reusability,one usually has to sacrifice modeling,and vice versa. For further informationon mixin inheritance, refer to Brachaand Cook [1990].

3.8 Life-Time Sharing Versus Creation-Time Sharing

Inheritance is a familiar concept fromthe real world. All living organisms in-herit genetic information from their an-



cestors, and thus inheritance serves asone of the fundamental mechanisms formaintaining life on earth. Besides itsbiological meaning, the term inheri-tance has various uses in human lan-guages. For instance, it is common tospeak of cultural inheritance (“Aborigi-nals inherited their traditions and cus-toms from their ancestors”), economicinheritance (“Frank inherited a lot ofmoney from his aunt”), inheritance ofstatus (“princess Victoria inherited herrank from her father, the king of Swe-den”) and so on. The term inheritancecan also have more colloquial uses suchas “this paper inherited a lot of ideasfrom my earlier work.” All these uses ofthe term inheritance have certainthings in common. In particular, inheri-tance is synonymous with receiving; inmost sentences the verb inherit could bereplaced with receive and the meaningof the sentence would remain the same.Note that receiving implies that theremust necessarily be at least two sepa-rate entities—the donor and the receiv-er—that participate in the inheritanceprocess.A characteristic aspect of inheritance

is sharing. As a result of inheritance,the donor and receiver are expected toshare something with each other. Shar-ing need not be physical, however. Forinstance, although it is common to saythat the child “shares the blue eyes ofhis father”, it does not mean that thefather and child will have to use thesame pair of eyes. Similarly, althoughidentical twins “share” the same geneticinformation, they are nevertheless twoseparate persons. In general, in its realworld meaning, inheritance usually re-fers to very transitory relationships be-tween things. In biological inheritance,for instance, the combination of geneticinformation takes place within a shortperiod of time, and the resulting new“abstraction” later becomes completelyindependent of its parent (well, at leastin principle, although in case of humanbeings the economic ties usually re-main. . .). This independence is reason-able, because it would be impractical for

parents and children to physically shareorgans with each other.In object-oriented programming the

meaning of inheritance is somewhat dif-ferent. Although inheritance still basi-cally implies receiving, in object-ori-ented programs inheritance usuallycreates much stronger relationships be-tween things than in the real world. Forinstance, when a subclass inherits prop-erties from its superclass, it is commonthat the methods of the superclass aremade available to the subclass by phys-ically sharing the same code. Althoughsuch “Siamese” sharing is alien to bio-logical inheritance, it is reasonable inprogramming, because requiring every-thing to be duplicated in the subclasswould waste a lot of memory. Snyderhas expressed this by claiming that “akey goal for any implementation of anobject-oriented language is to allow thesame compiled code to be used for eachclass that inherits a given method”[Snyder 1986b]. Not all inheritance inobject-oriented programming results inphysical sharing, however. For instance,the instance variables in instances ofclasses are always distinct from those inthe instances of superclasses.From the theoretical viewpoint, it is

useful to make a distinction betweentwo fundamental forms of sharing thatserve as a basis for property inheri-tance: life-time sharing and creation-time sharing. Life-time sharing refers tophysical sharing between parents andchildren. Once the sharing relationshipbetween parent and child has been es-tablished, the child remains sharing theproperties of its parent until the rela-tionship is removed. Furthermore, everychange to the parent is implicitly re-flected to the child. Creation-time shar-ing, in turn, implies that sharing occursonly while the receiving process is inprogress. Creation-time sharing is char-acterized by the independent evolutionof the parent and the child, and is typi-cal of the real world. Delegation dis-cussed in Section 3.2 results in life-timesharing, whereas concatenation resultsin creation-time sharing. The notions of



life-time sharing and creation-timesharing were introduced by Dony et al.[1992], who realized that these conceptsare useful in analyzing the differencesbetween various prototype-based object-oriented systems.The forms of sharing have a profound

effect on the semantics of object-ori-ented languages. Generally speaking,inheritance in real-world object-ori-ented languages can occur at three dif-ferent levels: behavior, state and struc-ture. Inheritance of behavior refers tothe passing of operations from parentsto their children. Since operations aretypically immutable, in many cases thiscan be accomplished simply by sharingcode. Inheritance of state, in turn, refersto the passing of contents (values) ofvariables from parents to the children.This can imply either sharing or dupli-cation, depending on what is appropri-ate in each particular situation. Sharingof state leads to objects whose states areintimately connected to each other andwhich thus are dependent on each other.Duplication of state, on the other hand,leads to independent objects [Stein1987]. Note that inheritance of state isnot typically possible in class-based sys-tems, because in such systems inheri-tance occurs between definitions of ob-jects (i.e., classes) rather than betweenobjects themselves. Instead, class inher-itance supports inheritance of structure,by which it is meant that normally onlythe information that is needed for re-constructing (allocating) the inheritedinstance variables is passed to descen-dants. This implies that there must bean additional mechanism to pass infor-mation about instance variables to sub-classes. Some prototype-based lan-guages provide special copy-down slotsfor this purpose.

3.9 Single Dispatching Versus MultipleDispatching

Most object-oriented systems are basedon single dispatching. Messages aresent to distinguished receiver objects,and the runtime type of the receiver

determines the method that is invokedby the message. The possible parame-ters in the message are passed on to theinvoked method, but do not participatein the actual lookup. Although this ap-proach is intuitive and works well inmost situations, it has some drawbacks.For instance, one implication is that abinary expression such as “514” getsthe unnatural interpretation.

5.plus(4).

In other words, 5 is treated as the re-ceiver of the message plus, while 4 isregarded as a parameter that plays norole in actual method lookup. Althoughsuch “currying” works fine in most situ-ations, it is conceptually undesirablesince in arithmetic expressions righthand sides are usually no less impor-tant than left hand sides. It can alsohave a negative effect on program read-ability. For instance, in Smalltalk allbinary expressions are parsed left toright, and normal arithmetic precedencerules do not apply. This makes mathe-matical expressions in Smalltalk differ-ent from those in most other languagesin which multiplication and divisiontake precedence over addition and sub-traction [Goldberg and Robson 1989, p.28].Besides conceptual problems, single

dispatching can also lead to some moretechnical problems and require duplica-tion of code. In order to make singledispatching handle properly situationsin which the same type of object mayreceive different kinds of parameters,the use of additional control structuresis usually needed. For instance, sendinga message “5 1 4.4” requires the integermethod 1 to be able to check at runtimewhether the parameter is an integer ora floating point number, and handleboth integer and floating point addition.Conversely, since it is equivalently legalfor the programmer to send a message“4.4 1 5,” the floating point class mustinclude the corresponding code to han-dle both real numbers and integers. Asa result, the same pieces of code may



have to be included in two places, or, ifthe message is nary rather than binary,in n places.In general, traditional message pass-

ing schemes are sometimes too “selfish.”There is a single receiver whose typedetermines which method is executed,while the parameters are ancillary andhave no role in method selection. Anobject-oriented language based on thiskind of an approach is termed a singledispatching language. In many situa-tions, however, it would be beneficial togeneralize the message binding mecha-nism to more than just single receiver.To surmount the limitations of singledispatching languages, some object-ori-ented languages include a more generalform of message passing in which multi-ple arguments to a message can partici-pate in the lookup process. These lan-guages are called multiple dispatchinglanguages. Since methods in multipledispatching languages may belong toseveral classes simultaneously, they arecalled multimethods. Multiple dispatch-ing is common in Lisp-based object-ori-ented systems, where multimethods areknown as generic methods [DeMichieland Gabriel 1987]. Multimethods werepioneered in CommonLoops [Bobrow etal. 1986], but the best-known multipledispatching object-oriented language oftoday is CLOS [DeMichiel and Gabriel1987; Keene 1989].Some researchers claim that multiple

dispatching provides increased expres-sive power over single dispatching[Chambers 1992]. With multimethods,the message lookup may involve all ar-guments, not just the receiver, and thusthe above mentioned problems with the“asymmetry” of single dispatching canbe avoided. Multiple dispatching is farfrom being widely accepted, however.Multiple dispatching languages are gen-erally more complex than single dis-patching languages, and their imple-mentations have not traditionally beenvery efficient. In practice, the biggestsingle concern to the programmers ishowever that languages supportingmultiple dispatching do not “feel object-

oriented.” This feeling reflects a basicdifference in the programming stylesencouraged by single and multiple dis-patching systems [Chambers 1992].When using a single dispatching lan-guage, the programmer mentally fo-cuses on defining abstract data types(ADTs), associating operations with thedata types for which they are imple-mented. These operations are “con-tained” in the data type, and togetherthe operations and the data form anencapsulated whole. A whole design andimplementation methodology has beendeveloped around this ADT-orientedprogramming style.Multiple dispatching languages do

not provide much linguistic support forthe ADT-oriented programming style.Since multimethods are dispatched onmultiple arguments, they are not con-tained in any single class, and the ADT-oriented view with strong encapsulationbreaks down. In practice, the program-ming style encouraged by multiple dis-patching systems seems to be closer tofunctional, or traditional proceduralprogramming style than ADT style. Tomany advocates of object-oriented pro-gramming, multimethods—having origi-nated from Lisp-based systems—seemlike an ad hoc solution that is a conse-quence of trying to fit round objects tothe square world of functions. This feel-ing is reinforced by the fact that multi-methods do not “look object-oriented”either. In multiple dispatching lan-guages the use of the object-orientedobject.message(parameters) notation isdiscouraged, and the traditional func-tion(parameters) or Lisp-like (functionparam1 . . . paramN) notation is usedinstead. Although some researchershave proposed (receiver1, receiver2, . . . ,receiverN).message notation as a com-promise, these notations are not as wellsuited to ADT programming style as thenormal dot notation or its equivalents.Recently Chambers, one of the origi-

nal implementors of the Self language[Ungar and Smith 1987], has spokenstrongly in favor of multimethods[Chamber 1992]. One of Chambers’



main arguments is that problems withmultiple dispatching arise mainly fromthe limitations of text-based program-ming, and by providing a good graphicalprogramming environment, most of theproblems with multimethods disappear.Instead of placing multimethods outsideof any single class, or by duplicating thesame definition in every participatingclass, a good visual browser would auto-matically display the same multimethodin association with all its classes. Intu-itively, this sounds like a good idea, butit still remains to be seen whether mul-tiple dispatching really catches on inthe object-oriented community.

3.10 Classifying Inheritance Mechanisms

Earlier in the article we saw that whileinheritance is a simple linguistic mech-anism with relatively straightforwardsemantics from the theoretical point ofview, many variations of inheritance ex-ist that tend to make the analysis ofinheritance difficult in practice. In addi-tion to basic questions—such aswhether the system is based on classesor prototypes, or whether it supportssingle or multiple inheritance—there isa large number of more elementary is-sues that have a considerable impact onthe semantics and pragmatics of thesystem. When implemented in concreteobject-oriented programming languages,typically these mechanisms tend to in-terfere with each other, making theanalysis and comparison of the lan-guages complicated.In trying to understand the concrete

realizations of inheritance in object-ori-ented programming languages, it is use-ful to use a progressive approach, i.e., tostart from conceptually simpler issuesand then gradually progress towardsmore complicated aspects. The followingkind of three-level taxonomy has provedhelpful in analyzing inheritance in ob-ject-oriented programming languages.

(1) Inheritance as incremental modifi-cation. As discussed in Section2.3.1, the “core” of inheritance is

incremental modification. If this cri-terion is not fulfilled, then we arenot talking about inheritance in theobject-oriented sense.

(2) Interface inheritance. At this level,inheritance is viewed as an interfacecombination or name space combi-nation mechanism. Questions per-taining to the management of theactual properties (methods and vari-ables) of objects are ignored.

(3) Property inheritance. The actualproperties (methods and variables)of objects are included in the analy-sis.

Figure 14 gives an overview of theissues and sources of variability thatarise at each level. For a more detailedtreatment on the subject, refer toTaivalsaari [1993c].

4. CONCLUSION

Broadly speaking, the history of software develop-ment is the history of ever-later binding time.

—Encyclopedia of Computer Science

In this article we have surveyed thenotion of inheritance, examining its in-tended and actual usage, its essenceand its varieties. We realized that al-though inheritance was originally intro-duced as a mechanism to support con-ceptual specialization, in reality manyalternative roles for inheritance can berecognized, ranging from conceptualmodeling to implementation-level usage(e.g., using inheritance simply as a codesharing mechanism to save storagespace or programming effort). Also, wepointed out that there is no single, com-monly accepted model of inheritance,but a lot of variations of the same basictheme exist.The fundamental observation under-

lying object-oriented inheritance mecha-nisms is that they all are essentiallyincremental modification mechanisms,i.e., mechanisms that allow existingprograms to be extended and refinedwithout editing existing code. In gen-eral, inheritance can be defined gener-



ally as an incremental modificationmechanism in the presence of late-boundself-reference. Although object-orientedprogramming has many other benefitscompared to other programming para-digms, none of them seems as profoundas the incremental capability. To con-clude, let us quote Stein et al. [1988]who have noted that “the true value ofobject-oriented techniques as opposed toconventional programming techniquesis not that they can do things the con-ventional techniques can’t, but thatthey can often extend behavior by add-ing new code in cases where conven-tional techniques would require editingexisting code instead.” This capturesthe heart of the matter.

REFERENCES

AKSIT, M. AND TRIPATHI, A. 1988. Data abstractionmechanisms in Sina/st. In OOPSLA’88 Con-ference Proceedings (San Diego, California,Sept. 25–30). ACM SIGPLAN Not. 23, 11(Nov.), 267–275.

AMERICA, P. 1987. Inheritance and subtyping in aparallel object-oriented language. In ECOOP’87: European Conference on Object-OrientedProgramming (Paris, France, June 15–17).Lecture Notes in Computer Science 276,Springer-Verlag, 234–242.

AMERICA, P. 1990. Designing an object-oriented pro-gramming language with behavioural subtyping.In Proceedings of the Foundations of Object-Ori-ented Languages, REX School/Workshop. J. W.De Bakker, W. P. De Roever, G. Rozenberg, Eds.(Noordwijkerhout, The Netherlands, May28–June 1). Lecture Notes in Computer Science489, Springer-Verlag, 1991, 60–90.

Figure 14. A simple taxonomy for analyzing inheritance mechanisms.



BLASCHEK, G. 1991. Type-safe OOP with proto-types: the concepts of Omega. Structured Pro-gram. 12, 12 (Dec.) 1–9.

BLASCHEK, G. 1994. Object-Oriented Programmingwith Prototypes. Springer-Verlag.

BOBROW, D. G., KAHN, K., KICZALES, G., MASINTER,L., STEFIK, M. AND ZDYBEL, F. 1986. Common-Loops: merging Lisp and object-oriented pro-gramming. In OOPSLA’86 Conference Pro-ceedings (Portland, Oregon, Sept. 26–Oct. 2).ACM SIGPLAN Not. 21, 11 (Nov.), 17–29.

BORGIDA, A., MYLOPOULOS, J. AND WONG, H. K. T.1984. Generalization/specialization as a basisfor software specification. In On ConceptualModelling: Perspectives from Artificial Intelli-gence, Databases, and Programming Lan-guages, M. L. Brodie, J. Mylopoulos, J. W.Schmidt, Eds. Springer-Verlag, 87–117.

BORNING, A. H. AND O’SHEA, T. 1987. Deltatalk: anempirically and aesthetically motivated sim-plification of the Smalltalk-80 language. InECOOP’87: European Conference on Object-Oriented Programming (Paris, France, June15–17). Lecture Notes in Computer Science276, Springer-Verlag, 1–10.

BORNING, A. H. 1986. Classes versus prototypes inobject-oriented languages. In Proceedings ofACM/IEEE Fall Joint Computer Conference,(Nov.) 36–40.

BRACHA, G. 1992. The programming language Jig-saw: Mixins, modularity and multiple inheri-tance. Ph.D. thesis, Univ. of Utah, March.

BRACHA, G. AND COOK, W. 1990. Mixin-based in-heritance. In OOPSLA/ECOOP’90 ConferenceProceedings (Ottawa, Canada, Oct. 21–25).ACM SIGPLAN Not. 25, 10 (Oct.), 303–311.

BRACHA, G. AND LINDSTROM, G. 1992. Modularitymeets inheritance. In Proceedings of the 1992International Conference on Computer Lan-guages (Oakland, California, April 20–23),IEEE Computer Society Press, 282–290.

BRACHMAN, R. 1983. What Is-a is and isn’t? IEEEComput. 16, 10 (Oct.) 30–36.

BRACHMAN, R. 1985. I lied about the trees—or,defaults and definitions in knowledge repre-sentation. AI Magazine 6, 3 (Fall) 80–93.

BRODIE, M. L. 1983. Association: a database ab-straction for semantic modelling. In Entity-Relationship Approach to Information Model-ing and Analysis. P. P. Chen, Ed. ElsevierScience Publishers (North-Holland), 577–602.

CARDELLI, L. 1984. A semantics of multiple inher-itance. In Semantics of Data Types, G. Kahn,D. B. MacQueen, G. Plotkin, Eds. LectureNotes in Computer Science 173, Springer-Ver-lag, 51–67.

CHAMBERS, C. 1992. Object-oriented multi-meth-ods in Cecil. In ECOOP’92: European Confer-ence on Object-Oriented Programming (Utre-cht, The Netherlands, June 29–July 3).

Lecture Notes in Computer Science 615,Springer-Verlag, 33–56.

CHAMBERS, C. 1993. Predicate classes. InECOOP’93: European Conference on Object-Oriented Programming (Kaiserslautern, Ger-many, July 26–30). Lecture Notes in Com-puter Science 707, Springer-Verlag, 268–296.

CHAMBERS, C., UNGAR, D., CHANG, B.-W. AND

HOLZLE, U. 1991. Parents are shared parts ofobjects: inheritance and encapsulation in Self.Lisp Symbolic Comput. 4, 3 (Jun.).

COOK, W. R., HILL, W. L. AND CANNING, P. S. 1990.Inheritance is not subtyping. In Proceedingsof the Seventeenth Annual ACM Symposiumon Principles of Programming Languages(San Francisco, California, Jan. 17–19), ACMPress, 125–135.

COOK, W. R. 1989. A denotational semantics ofinheritance. Ph.D. thesis, Brown University,Tech. Rep. CS-89-33, May.

COOK, W. R. 1989. A proposal for making Eiffeltype-safe. Comput. J. 32, 4 (Aug.), 305–311.Also in ECOOP’89: Proceedings of the ThirdEuropean Conference on Object-Oriented Pro-gramming (Nottingham, England, July 10–14). The British Computer Society WorkshopSeries, Cambridge, Univ. Press, 57–70.

COOK, W. R. 1992. Interfaces and specificationsfor the Smalltalk-80 collection classes. InOOPSLA’92 Conference Proceedings (Vancou-ver, Canada, Oct. 18–22). ACM SIGPLANNot. 27, 10 (Oct.), 1–15.

COOK, W. R. AND PALSBERG, J. 1989. A denota-tional semantics of inheritance and its cor-rectness. In OOPSLA’89 Conference Proceed-ings (New Orleans, Louisiana, Oct. 1–6).ACM SIGPLAN Not. 24, 10 (Oct.), 433–443.

DAHL, O-J., DIJKSTRA, E. W. AND HOARE, C. A. R.1972. Structured Programming. AcademicPress.

DAHL, O-J., MYHRHAUG, B. AND NYGAARD, K. 1968.SIMULA 67 common base language. Tech.Rep., Norwegian Computing Center, Oslo,May.

DANFORTH, S. AND TOMLINSON, C. 1988. Type theo-ries and object-oriented programming. ACMComput. Surv. 20, 1 (Mar.) 29–72.

DEMICHIEL, L. G. AND GABRIEL, R. P. 1987. TheCommon Lisp object system: An overview. InECOOP’87: European Conference on Object-Oriented Programming (Paris, France, June15–17). Lecture Notes in Computer Science276, Springer-Verlag, 157–170.

DEUTSCH, L. P. AND SCHIFFMAN, A. M. 1984. Effi-cient implementation of the Smalltalk-80 sys-tem. In Proceedings of the Eleventh AnnualACM Symposium on Principles of Program-ming Languages (Salt Lake City, Utah, Jan.15–18), ACM Press, 297–302.

DONY, C., MALENFANT, J. AND COINTE, P. 1992.Prototype-based languages: from a new taxon-



omy to constructive proposals and their vali-dation. In OOPSLA’92 Conference Proceedings(Vancouver, Canada, Oct. 18–22). ACM SIG-PLAN Not. 27, 10 (Oct.), 201–217.

DRIESEN, K., HOLZLE, U. AND VITEK, J. 1995. Mes-sage dispatch on pipelined processors. InECOOP’95: European Conference on Object-Oriented Programming (Åarhus, Denmark,Aug. 7–11). Lecture Notes in Computer Sci-ence. 952, Springer-Verlag, 253–282.

DUCOURNAU, R. AND HABIB, M. 1987. On somealgorithms for multiple inheritance in object-oriented programming. In ECOOP’87: Euro-pean Conference on Object-Oriented Program-ming (Paris, France, June 15–17). LectureNotes in Computer Science 276, Springer-Ver-lag, 243–252.

ELLIS, M. A. AND STROUSTRUP, B. 1990. The Anno-tated C11 Reference Manual. Addison-Wesley.

GOLDBERG, A. AND ROBSON, D. 1989. Smalltalk-80:The Language. Addison-Wesley.

GRAVER, J. O. AND JOHNSON, R. E. 1990. A typesystem for Smalltalk. In Proceedings of theSeventeenth Annual ACM Symposium onPrinciples of Programming Languages (SanFrancisco, California, Jan. 17–19), ACMPress, 136–150.

HALBERT, D. C. AND O’BRIEN, P. D. 1987. Usingtypes and inheritance in object-oriented pro-gramming. IEEE Softw. 4, 5 (Sept.), 71–79.Revised version in ECOOP’87: European Con-ference on Object-Oriented Programming (Par-is, France, June 15–17). Lecture Notes inComputer Science 276, Springer-Verlag, 20–31.

HARPER, R. AND PIERCE, B. 1991. A record calculusbased on symmetric concatenation. In Pro-ceedings of the Eighteenth Annual ACM Sym-posium on Principles of Programming Lan-guages (Orlando, Florida, Jan. 21–23), ACMPress, 131–142.

HENDLER, J. 1986. Enhancement for multiple in-heritance. In OOPSLA’86 Conference Proceed-ings (Portland, Oregon, Sept. 26–Oct. 2).ACM SIGPLAN Not. 21, 11 (Nov.), 98–106.

HARTMANN, T., JUNGCLAUS, R. AND SAAKE, G. 1992.Aggregation in a behavior oriented objectmodel. In ECOOP’92: European Conference onObject-Oriented Programming (Utrecht, TheNetherlands, June 29–July 3). Lecture Notesin Computer Science 615, Springer-Verlag,57–77.

JOHNSON, R. E. 1986. Type-checking Smalltalk.OOPSLA’86 Conference Proceedings (Port-land, Oregon, Sept. 26–Oct. 2). ACM SIG-PLAN Not. 21, 11 (Nov.), 315–321.

KEENE, S. E. 1989. Object-Oriented Programmingis Common Lisp: A Programmer’s Guide toCLOS. Addison-Wesley.

KRISTENSEN, B. B., MADSEN, O. L., MØLLER-PED-ERSEN, B. AND NYGAARD, K. 1983. Abstractionmechanisms in the Beta programming lan-

guage. In Proceedings of the Tenth AnnualACM Symposium on Principles of Program-ming Languages (Austin, Texas, Jan. 24–26),ACM Press, 285–298.

KNUDSEN, J. L. AND MADSEN, O. L. 1988. Teachingobject-oriented programming is more thanteaching object-oriented programming lan-guages. In ECOOP’88: European Conferenceon Object-Oriented Programming (Oslo, Nor-way, Aug. 15–17). Lecture Notes in ComputerSci. 276, Springer-Verlag, 21–40.

KNUDSEN, J. L. 1988. Name collision in multipleclassification hierarchies. In ECOOP’88: Eu-ropean Conference on Object-Oriented Pro-gramming (Oslo, Norway, Aug. 15–17). Lec-ture Notes in Computer Sci. 276, Springer-Verlag, 93–109.

KORSON, T. AND MCGREGOR, J. D. 1990. Under-standing object-oriented: A unifying para-digm. Commun. ACM 33, 9 (Sept.) 40–60.

KRUEGER, C. W. 1992. Software reuse. ACM Com-put. Surv. 24, 2 (June) 131–183.

LALONDE, W. R. 1989. Designing families of datatypes using exemplars. ACM Trans. Program.Lang. Syst. 11, 2 (Apr.) 212–248.

LALONDE, W. R. AND PUGH, J. 1991. Subclassing Þsubtyping Þ is-a. J. Object-Oriented Program.3, 5 (Jan.), 57–62.

LALONDE, W. R., THOMAS, D. A. AND PUGH, J. R.1986. An exemplar based Smalltalk. InOOPSLA’86 Conference Proceedings (Port-land, Oregon, Sept. 26–Oct. 2). ACM SIG-PLAN Not. 21, 11 (Nov.), 322–330.

LANG, K. J. AND PEARLMUTTER, B. A. 1986. Oaklisp:an object-oriented Scheme with first classtypes. In OOPSLA’86 Conference Proceedings(Portland, Oregon, Sept. 26–Oct. 2). ACMSIGPLAN Not. 21, 11 (Nov.), 30–37.

LIEBERHERR, K. J., HOLLAND, I. M. AND RIEL, A. J.1988. Object-oriented programming: an objec-tive sense of style. In OOPSLA’88 ConferenceProceedings (San Diego, California, Sept. 25–30). ACM SIGPLAN Not. 23, 11 (Nov.) 323–334.

LIEBERHERR, K. J. AND HOLLAND, I. M. 1989. As-suring good style for object-oriented program-ming. IEEE Softw. 6, 5 (Sept.) pp. 38–48.

LIEBERMAN, H. 1986. Using prototypical objectsto implement shared behavior in object-ori-ented systems. In OOPSLA’86 ConferenceProceedings (Portland, Oregon, Sept. 26–Oct.2). ACM SIGPLAN Not. 21, 11 (Nov.), 214–223.

LISKOV, B. H. 1987. Data abstraction and hierar-chy. In Addendum to the Proceedings ofOOPSLA’87. ACM SIGPLAN Not. 23, 5 (May),1988, 17–34.

LOOMIS, M. E. S., SHAH, A. V. AND RUMBAUGH, J. E.1987. An object modeling technique for con-ceptual design. In ECOOP’87: European Con-ference on Object-Oriented Programming (Par-is, France, June 15–17). Lecture Notes in



Computer Science 276, Springer-Verlag, 192–202.

MADSEN, O. L. AND MØLLER-PEDERSEN, B. 1988.What object-oriented programming may beand what it does not have to be? InECOOP’88: European Conference on Object-Oriented Programming (Oslo, Norway, Aug.15–17). Lecture Notes in Computer Science.276, Springer-Verlag, 1–20.

MADSEN, O. L. AND MØLLER-PEDERSEN, B. 1989.Virtual classes: a powerful mechanism in ob-ject-oriented programming. In OOPSLA’89Conference Proceedings (New Orleans, Louisi-ana, Oct. 1–6). ACM SIGPLAN Not. 24, 10(Oct.), 397–406.

MADSEN, O. L., MAGNUSSON, B. AND MØLLER-PED-ERSEN, B. 1990. Strong typing of object-ori-ented programming revisited. In OOPSLA/ECOOP’90 Conference Proceedings (Ottawa,Canada, Oct. 21–25). ACM SIGPLAN Not. 25,10 (Oct.), 140–149.

MAGNUSSON, B. 1991. Implementation of inheri-tance in Simula. Personal communication.

MARCOTTY, M. AND LEDGARD, H. 1987. TheWorld of Programming Languages. Springer-Verlag.

MATTOS, N. M. 1988. Abstraction concepts: thebasis for knowledge modeling. In Proceedingsof the 7th International Conference on Entity-Relationship Approach C. Batini, Eds. Rome,(Nov. 16–18), 331–350.

MEYER, B. 1988. Object-Oriented Software Con-struction. Prentice-Hall.

MOON, D. A. 1986. Object-oriented programmingwith Flavors. In OOPSLA’86 Conference Pro-ceedings (Portland, Oregon, Sept. 26–Oct. 2).ACM SIGPLAN Not. 21, 11 (Nov.), 1–8.

NYGAARD, K. AND DAHL, O-J. 1987. The develop-ment of the Simula languages. In ACM SIG-PLAN History of Programming LanguagesConference, Ed. (Los Angeles, California, June1–3), R. L. Wexelblat, ACM SIGPLAN Not.13, 8 (Aug.) 245–272.

PALSBERG, J. AND SCHWARTZBACH, M. I. 1990. Typesubstitution for object-oriented programming.In OOPSLA/ECOOP’90 Conference Proceed-ings (Ottawa, Canada, Oct. 21–25). ACM SIG-PLAN Not. 25, 10 (Oct.), 151–159.

PALSBERG, J. AND SCHWARTZBACH, M. I. 1991.Static typing for object-oriented program-ming. Aarhus University Tech. Rep. DAIMIPB-355, Denmark, June.

PEDERSEN, C. H. 1989. Extending ordinary inheri-tance schemes to include generalization. InOOPSLA’89 Conference Proceedings (New Or-leans, Louisiana, Oct. 1–6). ACM SIGPLANNot. 24, 10 (Oct.), 407–417.

PERNICI, B. 1990. Object with roles. In Proceedingsof the ACM/IEEE Conference of Office Informa-tion Systems (Cambridge, Massachusetts, Apr.

25–27), F. H. Lochovsky and R. B. Allen, Eds.ACM SIGOIS Bull. 11, 2/3 (Apr.) 205–215.

PLATO. The Republic. Kustannusosakeyhtio Otava,Keuruu, Finland. (Finnish translation, 1981).

PORTER, H. H. III. 1992. Separating the subtypehierarchy from the inheritance of implementa-tion. J. Object-Oriented Program. 4, 9 (Feb.)20–29.

RAJ, R. K. AND LEVY, H. M. 1989. A compositionalmodel for software reuse. The Comput. J. 32, 4(Aug.) 312–322.

REDDY, U. S. 1988. Objects as closures: abstractsemantics of object-oriented languages. InProceedings of the ACM Conference on Lispand Functional Programming (Snowbird,Utah, July 25–27), 289–297.

RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY,F. AND LORENSEN, W. 1991. Object-OrientedModeling and Design. Prentice-Hall.

SAKKINEN, M. 1989. Disciplined inheritance. InECOOP’89: Proceedings of the Third Euro-pean Conference on Object-Oriented Program-ming (Nottingham, England, July 10–14).The British Computer Society Workshop Se-ries, Cambridge University Press, 39–56.

SCHAFFERT, C., COOPER, T., BULLIS, B., KILLIAN, M.AND WILPOLT, C. 1986. An introduction toTrellis/Owl. In OOPSLA’86 Conference Pro-ceedings (Portland, Oregon, Sept. 26–Oct. 2).ACM SIGPLAN Not. 21, 11 (Nov.), 9–16.

SCIORE, E. 1989. Object specialization. ACMTrans. Inf. Syst. 7, 2 (April) 103–122.

SMITH, J. M. AND SMITH, D. C. P. 1977. Databaseabstractions: aggregation. Commun. ACM 20,6 (Jun.) 405–413.

SMITH, J. M. AND SMITH, D. C. P. 1977. Databaseabstractions: aggregation and generalization.ACM Trans. Database Syst. 2, 2 (Jun.) 105–133.

SMITH, D. C. P. AND SMITH, J. M. 1980. Conceptualdatabase design. Also in Tutorial on SoftwareDesign Techniques, 4th ed., Freeman, P.,Wasserman, A. I. Eds. IEEE Computer Soci-ety Press, 1983, 437–460.

SNYDER, A. 1986. Encapsulation and inheritancein object-oriented programming languages. InOOPSLA’86 Conference Proceedings, (Port-land, Oregon, Sept. 26–Oct. 2). ACM SIG-PLAN Not. 21, 11 (Nov.), 38–45.

SNYDER, A. 1986. CommonObjects: an overview. InACM SIGPLAN Not. 21, 10 (Oct.), 19–28.

SNYDER, A. 1991. Modeling the C11 object model:an application of an abstract object model. InECOOP’91: European Conference on Object-Oriented Programming (Geneva, Switzerland,July 15–19). Lecture Notes in Computer Sci-ence. 512, Springer-Verlag, 1–20.

SOWA, J. F. 1984. Conceptual Structures: Informa-tion Processing in Mind and Machine. Addi-son-Wesley.

STEIN, L. A. 1987. Delegation is inheritance. InOOPSLA’87 Conference Proceedings (Orlando,



Florida, Oct. 4–8). ACM SIGPLAN Not. 22,12 (Dec.), 138–146.

STEIN, L. A., LIEBERMAN, H. AND UNGAR, D. 1988. Ashared view of sharing: the treaty of Orlando.In Object-Oriented Concepts, Applications andDatabases, W. Kim and F. Lochowsky, Eds.Addison-Wesley, 31–48.

STEIN, L. A. 1989. Towards a unified method ofsharing in object-oriented programming. InWorkshop on Inheritance Hierarchies inKnowledge Representation and Programming(Viareggio, Italy, Feb. 6–8).

TAIVALSAARI, A. 1993. On the notion of object. J.Syst. Softw. 21, 1 (Apr.) 3–16.

TAIVALSAARI, A. 1993. Object-oriented program-ming with modes. J. Object-Oriented Pro-gram. 6, 3 (Jun.) 25–32.

TAIVALSAARI, A. 1993. A critical view of inheritanceand reusability in object-oriented programming.Ph.D. thesis, Jyvaskyla Studies in ComputerScience, Economics and Statistics 23, Univ. ofJyvaskyla, Finland, Dec. 276 pages.

UNGAR, D. AND SMITH, R. B. 1987. Self: the powerof simplicity. In OOPSLA’87 Conference Pro-ceedings (Orlando, Florida, Oct. 4–8). ACMSIGPLAN Not. 22, 12 (Dec.), 227–241.

WEGNER, P. 1987. The object-oriented classifica-tion paradigm. In Research Directions in Ob-ject-Oriented Programming. B. Shriver and P.Wegner, Eds. The MIT Press, 479–560.

WEGNER, P. 1990. Concepts and paradigms of ob-

ject-oriented programming. ACM OOPS Mes-senger 1, 1 (Aug.) 7–87.

WEGNER, P. AND SHRIVER, B. Eds. 1986. Object-oriented programming workshop (YorktownHeights, New York, June 9–13). ACM SIG-PLAN Not. 21, 10 (Oct.).

WEGNER, P. AND ZDONIK, S. B. 1988. Inheritance asan incremental modification mechanism orwhat Like is and isn’t like. In ECOOP’88:European Conference on Object-Oriented Pro-gramming (Oslo, Norway, Aug. 15–17). Lec-ture Notes in Computer Sci. 276, Springer-Verlag, 55–77.

WILKES, W. 1988. Instance inheritance mecha-nisms for object-oriented databases. In Ad-vances in Object-Oriented Databased Systems,2nd International Workshop on Object-Ori-ented Database Systems, (Bad Munster amStein-Ebernburg, Germany, Sept. 27–30),K. R. Dittrich, Ed. Lecture Notes in ComputerScience 334, Springer-Verlag, 274–279.

WIRTH, N. 1971. Program development by step-wise refinement. Commun. ACM 14, 4 (Apr.)221–227.

WIRTH, N. 1985. Programming in Modula-2. 3rdEd. Springer-Verlag.

ZDONIK, S. B. 1986. Why properties are objects, orsome refinements of “is-a.” In Proceedings ofACM/IEEE Fall Joint Computer Conference,(Nov.) 41–47.

Received April 1994; revised September 1995; accepted January 1996



on the notion of inheritance - citeseer

Documents