Static Typing for Object-Oriented Programming

Transcription

1 Science of Computer Programming 23(1):19 53, Static Typing for Object-Oriented Programming Jens Palsberg Michael I. Schwartzbach Computer Science Department Aarhus University Ny Munkegade DK-8000 Århus C, Denmark Abstract We develop a theory of statically typed object-oriented languages. It represents classes as labeled, regular trees, types as finite sets of classes, and subclassing as a partial order on trees. We show that our subclassing order strictly generalizes inheritance, and that a novel genericity mechanism arises as an order-theoretic complement. This mechanism, called class substitution, is pragmatically useful and can be implemented efficiently. 1 Introduction Object-oriented programming is becoming widespread. Numerous programming languages supporting object-oriented concepts are in use, and theories about object-oriented design and implementation are being developed and applied [21, 3, 14]. An important issue in object-oriented programming is to obtain reusable software components [30]. This is achieved through the notions of object, class, inheritance, late binding, and the imperative constructs of variables and assignments. Such features are found for example in the Smalltalk language [25] in which a large number of reusable classes have been written. Smalltalk, however, is untyped. Though this is ideal for prototyping and exploratory development, a static type system is required to ensure that programs are readable, reliable, and efficient. This paper studies an idealized subset of Smalltalk, equipped with a novel static type system. Our analysis results in the definition of a new genericity mechanism, called class substitution, which we prove to be the order-theoretic complement of inheritance. 1

2 In the following section we briefly review the benefits of static typing. We argue that the choice of finite sets of classes as types can provide exactly those benefits. Furthermore, in this setting subtyping can be seen to be simply set inclusion. Finally, we compare this notion of type with others that have been proposed. In Section 3 we outline the example language. It is an idealized subset of Smalltalk, in which variables and parameters are declared together with types. The language has been simplified by the omission of blocks; instead, a primitive if-then-else is provided. We also give precise requirements for static correctness of programs, and introduce a mathematical framework in which we represent classes as labeled, regular trees. These representations abstract away from class names. In Section 4 we discuss inheritance and its interaction with mutually recursive classes. We also show that a program using inheritance can be transformed into one which does not. In Section 5 we structure the class representations with a partial order which generalizes inheritance. The intuition behind the order is that a subclass may extend the implementation and redefine the types consistently, while preserving the recursive structure of the superclass. All such generalized subclass relationships can be exploited by an implementation to provide reusable software components. The suggested implementation is a generalization of a naïve Smalltalk interpreter. We show that the partial order has the same characteristic properties as its subset inheritance: it is decidable, has a least element, has finite intervals, does not allow temporal cycles, and preserves subtyping. In Section 6 we prove that the generalized subclassing order is strictly more powerful than ordinary inheritance. We characterize the extra possibilities by showing that they form a suborder which is an order-theoretic orthogonal complement to the suborder formed by inheritance relationships. In Section 7 we develop the orthogonal complement of inheritance into a programming mechanism, called class substitution, which turns out to be a genericity mechanism. This means that our simple type system, though voided of e.g. type variables, still supports genericity. We extend the example language with syntax for class substitution, give example programs, and compare with parameterized classes. Finally, in Section 8 we use our framework to analyze the kind of type system which is common in existing object-oriented languages, for example C++ and Simula/Beta. The analysis yields an explanation of why these languages often allow loop-holes in the type system or resort to run-time type-checking in some cases. 2

3 2 Types Types are advantageous because an untyped program may be unreadable, unreliable, and inefficient. Any choice of type system for a language must be able to remedy some or all of the above deficiencies [29]. Types may be used as annotations, and those can be read not only by humans but also by the compiler which may be able to exhibit a safety-guarantee and perform compile-time optimizations. The safety-guarantee will typically state that operations are only performed on arguments of the proper types; in other words, certain run-time errors will not occur. In this section we present a new, simple type system for object-oriented languages and we argue why it yields the benefits stated above. We also examine other type systems and discuss similarities and differences. 2.1 Types are Sets of Classes class Record var key: Integer method getkey returns Integer key method setkey(k: Integer) returns Record key := k ; self end Record class File var buffer: Record method initialize returns File buffer := Record new ; buffer.setkey(17) ; self end File Figure 1: Records and Files. The basic metaphor in object-oriented programming is the object. An object groups together variables and procedures (called methods), and prevents direct outside access to the variables; it may be thought of as a module [58]. Objects are instances of classes, see for example figure 1. The class Record specifies a pattern from which all Record objects will be created. Such an object is created for example in class File by the expression Record new and it gets a separate copy of all variables. Note that also Integer is a class, though specified elsewhere, and that each method returns the result of its last expression. If nothing needs to be returned, then usually one returns the object itself, denoted by self. 3

4 The only possible interaction with an object is when sending a message to it when invoking one of its methods. For example, in class File the expression buffer.setkey(17) expresses the sending of the message setkey with argument 17 to the object in the variable buffer. If the object does not understand the message if its class does not implement a method with the specified name then the runtime error messagenotunderstood occurs. In a pure object-oriented language this is the only run-time error that can occur. The purpose of a type system is to allow the programmer to annotate programs with information about which methods are available in a given object, and to allow the compiler to guarantee the the error messagenotunderstood will never occur [4, 9]. The latter immediately enables compile-time optimizations because a number of checks need not be inserted into the code. In Smalltalk, any object can be assigned to any variable. Message sending is implemented by late binding, i.e., the message send is dynamically bound to an implementation depending on the class of the receiver. The fundamental question is: which messages will an object residing in a variable be able to respond to? Ignoring the possibility of doing flow analysis, the answer is: those methods that are common to the classes of the possible objects in that variable. This set of methods can be specified by simply listing the classes of the possible objects, because only finitely many classes occur in a given program. These observations lead us to define the notion of type that will be analyzed throughout this paper. A type is a finite set of classes. Note that a type can only contain classes that are part of the program. This corresponds to a closed-world assumption. Our types are more general than they may seem at first. Any kind of type expressions may be employed, providing that they can be interpreted as predicates on classes. In a given program only finitely many classes will satisfy any given predicate. The type can now be identified with the finite set; hence, we are justified in viewing our type system as being quite general. As an example of a type, consider again figure 1, where class File specifies a variable buffer of type Record. The type contains a single class, hence, only Record objects are allowed to reside in the variable. 2.2 Subtyping is Set Inclusion An object may have more than one type. Consider for example an instance of class Record. The singleton type containing just Record is a type of that instance, but so is also any superset. Henceforth, we will call a superset for a supertype, and a subset for a subtype. 4

5 When type-checking an assignment x := e (and similarly for a parameter passing), then it suffices to check that the static type of x is a supertype of the static type of e. This is because the assignment then will not violate the requirement that only objects of the static type of x can reside in x. If we had a more advanced kind of type expressions, then subtyping must be defined to coincide with or at least to respect inclusion of the corresponding sets. The nil object requires special attention. In Smalltalk it is an instance of the class undefinedobject, and it is the initial contents of variables when objects are created. This implies that we should want undefinedobject to be a member of all types. In this paper, we do not want to rely on any predefined classes, however, so we will treat nil in another way. Instead of having undefinedobject as an explicit member of all types, we will define nil to be a special primitive value which implicitly has the empty type and, hence, has all types. Treating nil as a non-instance is in line with its implementation in typed languages such as C++ [54], Eiffel [39], and Simula [22]/Beta [32]. In the language we later present, nil is in fact the only constant value. The language can be viewed as simply a calculus of pointers, in which it is quite natural that nil should enjoy a special status. 2.3 Inheritance is Not Subtyping Object-oriented programming differs from other programming paradigms in offering inheritance as a means for reusing class definitions. Inheritance can be viewed as a shorthand: it allows the definition of a class to be a modification of an existing one. More specifically, it allows the construction of subclasses by adding variables and methods, and by overriding method bodies [25, 57]. A thorough discussion of inheritance is given in a later section. The difference between inheritance and subtyping is illustrated in figure 2 which displays a class hierarchy discussed in [36], together with the corresponding type hierarchy. Notice that we turn the class hierarchy upside-down in order to get the smallest class at the bottom, and that the figure uses the notation C for the set of all subclasses of C, even potential ones. The class hierarchy is a tree, whereas the type hierarchy is a lattice. Note that the Beta group has suggested interpreting nil as an instance of an auxiliary class on top of the class hierarchy [36]. This is awkward because it implies that this class can be obtained by some sort of multiple inheritance of all other classes. This again implies that instances of this auxiliary class should be able to respond to any message; clearly nil is not able to do this. Our explanation of nil as a value having the empty type is more satisfactory: it reflects that nil can not respond to all messages, and that it can be assigned to any variable. In 5

6 object vehicle bus car vehicle object Class hierarchy (tree) {vehicle,bus,car} bus car {vehicle,bus} {bus,car} {vehicle,car} {bus} {vehicle} {car} Type hierarchy (lattice) Figure 2: The class and type hierarchies (excerpts). the language we later present, nil understands only the if-then-else message. 2.4 Other Type Systems Usually, formal models of typed object-oriented programming are based on the lambda calculus. They represent objects as records and methods as functions, and involve coercions together with subtypes [10, 41], polymorphic types [40, 13, 23], or F -bounded constraints [8, 15, 7] in the description of inheritance. In contrast, traditional object-oriented languages are not based on coercions and do not support methods as values. Furthermore, the coercion models while being very general in some respects do not support variables and assignments, because variable (mutable) types have no non-trivial subtypes, as observed by Cardelli [11]. In a functional language, an assignment must be emulated by the creation of an updated copy, and it is extremely hard to preserve the type of the original value. It was long believed that bounded parametric polymorphism was sufficient [13], but it has been realized that considerably more fine-grained type systems are required to handle even simple updates [12]. Graver and Johnson s type system for Smalltalk [29, 27, 28] has much in common with ours. Their types are essentially finite sets of classes, but they have to axiomatize a subtype relation that corresponds exactly to set inclusion because 6

7 the type system involves type variables. They also employ a notion of signature type which essentially denotes the finite set of subclasses of a given class, under our closed-world assumption. One strength of our type system is that it can avoid type variables and exclusively use the simple notion of sets of classes as types. The issue of genericity will instead be handled by generalizing the notion of subclassing. 3 The Example Language (Program) P ::= C 1... C n E (Class) C ::= class ClassId var D 1... D k M 1... M n end ClassId (Method) M ::= method MethodId (D 1... D k ) returns T E (Declaration) D ::= Id : T (Type) T ::= [selfclass] ClassId 1... ClassId n (Expression) E ::= Id := E E. MethodId (E 1... E n ) E ; E if E then E else E ClassId new selfclass new E instanceof ClassId self Id nil Figure 3: Syntax of the example language. Our example language is an idealized subset of Smalltalk, except that variables and parameters are declared together with a type, see figure 3. We also leave the issue of inheritance to the following section. In this section we briefly discuss the semantics of the language and state the precise rules for static correctness. We also introduce a convenient representation of classes. 3.1 Informal Semantics A program is a set of classes followed by an expression whose value is the result of executing the program. A class can contains variables and methods; a method consists of a name, an argument-list, a result-type, and an expression. The result of an assignment is the assigned value. A message send is executed by evaluating the receiver and the arguments, and if the class of the receiver implements a 7

8 method for the message, then a normal procedure call takes place; otherwise, the error messagenotunderstood occurs. The result of a sequence is the result of the last expression in that sequence. The if-then-else expression tests if the condition is non-nil. The expression selfclass new yields an instance of the class of self. The expression E instanceof ClassId yields a run-time check for class membership. If the check fails, then the expression evaluates to nil. The expression self denotes the receiver of the message, Id refers to instance variables and parameters, and nil is a primitive value. Note that selfclass can always be replaced by the name of the enclosing class. This is a convenient way of making recursion explicit. It is not sufficient for expressing mutually recursive classes, however. For that, it is necessary to use the class names directly. We have no primitive types (like integer and boolean) nor type constructors (like list) because we can program classes that encode them, see [44]. Note that we ignore the issues of concurrency and persistence [56]. 3.2 Static Correctness We define correctness of a method body with respect to the name of the enclosing class, and global and local environments. These can be uniquely determined from the program syntax. The global environment maps class names to class descriptions. A class description maps method names to method descriptions. A method description maps argument numbers to their declared types; for convenience, the result type is assumed to have number zero. The local environment is a finite map from names of instance variables and parameters to their declared types. We shall use the notation E :: τ to denote that the expression E is statically correct and has type τ. This property will be defined by means of a number of rules of the form Condition 1. Condition k E :: τ with the obvious interpretation: if all the conditions can be satisfied, then the conclusion follows. 8

9 The following rules exhaust the syntactic possibilities; the enclosing class has name C, the global environment is denoted by G, and the local environment is denoted by E. nil :: {} self :: {C} selfclass new :: {C} D new :: {D} id dom(e) early check Id :: E(Id) E :: τ E instanceof D :: {D} E i :: τ i if E 1 then E 2 else E 3 :: τ 2 τ 3 E i :: τ i E 1 ; E 2 :: τ 2 E :: τ 1 Id :: τ 2 τ 1 τ 2 Id:=E :: τ 1 E :: τ E i :: τ i c τ : m dom(g c) c τ : dom(g c m) = {0,..., n} c τ : τ i G c m i E. m(e 1... E n ) :: c τ G c m 0 subtype check early check early check subtype check Now, a program is statically correct when all method bodies have a typing in the corresponding environments. Note that really only two kinds of checks are performed: 9

10 early checks, which require the existence of certain declared names. subtype checks, which require inclusions between certain types. With this definition of static correctness, it should be obvious that variables of type T can only contain objects of type T; that if an expression is evaluated to a non-nil result, then the class of that result is contained in the type of the expression; and that we can guarantee that any message is sent to either nil or an instance of a class which implements a method for that message. Note that we ignore keeping track of nil-values; this can be treated separately by flow analysis. A formal proof of these claims should be based on a dynamic semantics of the example language [48, 31]. We will not go into the details in this paper, however, but move on to define a convenient representation of classes. 3.3 Tree Representations of Classes We shall work with a slightly abstracted form of classes, which will allow us to give a formal treatment of their relationships. The mathematical framework is a kind of labeled trees, which we shall call L- trees. Definition 3.1: Let Σ be a finite alphabet. An L-tree over Σ is an ordered, node-labeled, regular tree. We recall that a tree is regular when it has only finitely many different subtrees [20]. The labels are finite strings over Σ { }, where it is assumed that Σ. The empty label is denoted by Ω. We shall refer to the special symbol as a gap. It is further required that any node in an L-tree has exactly one subtree for each gap in its label. We have some notation associated with such trees. Definition 3.2: Let T be an L-tree. A tree address is a sequence of integers denoting a path from the root to a node; each integer denotes the number of a subtree in the given order. We write α T when α is a valid tree address in T. The empty tree address is denoted by λ. If α T then T [α] denotes the label with address α in T, and T α denotes the subtree of T whose root has address α. Note that T λ = T. We can now separate a class from its surrounding program and represent it as an 10

11 L-tree. Intuitively, the tree is a possibly infinite unfolding of the source code of the class. The labels will be source code with gaps in place of occurrences of class names. Recall that a class name may occur before new, after instanceof, and inside type expressions. We shall also replace occurrences of selfclass with gaps. The root label of a class representation is the gapped source code of the class. Let the classes in the program be C 1,...,C n and the corresponding root labels be L 1,..., L n. The trees tree(c 1 ),...,tree(c n ) are defined through the following regular equation system: tree(c 1 ) = L 1 ( X 1 ). tree(c n ) = L n ( X n ) Each X i is a list of subtrees, which is obtained as follows. Every subtree corresponds to a gap in the label L i. If the gap replaced the class C j, then the subtree is tree(c j ); if the gap replaced selfclass, then the subtree is tree(c i ). It is wellknown that such an equation system has a unique solution [19], which clearly is an L-tree. If any part of a class is recursive, then the tree will be infinite. Quite often, recursive types are represented as regular trees with nodes labeled by type constructors [2]. This is in fact what we have done, with the proviso that we consider every class as a user-defined type constructor rather than as a user-defined type. We have now abstracted away from the class names, which obviously cannot be uniquely recovered. We can, however, transform a tree T back into an equivalent program, prog(t ), by selecting a class name for every different subtree in T and reconstructing the syntax. The structural equivalence on classes simply says that two classes are equivalent if their trees are equal. It might be considered that the trees are not sufficiently abstract to deserve attention. For instance, we distinguish the order in which methods are implemented, and type expressions are interpreted as sequences rather than sets. Some tidying up is certainly possible: methods could be ordered in a canonical way, and type expressions could be normalized. For the purposes of this paper, however, such improvements are not really necessary. We shall mainly look at classes obtained as modifications of other classes, in which particular arbitrary choices are always carried along. The behavior of a class, for example an element of a Scott-domain, is clearly not a feasible representation it is too abstract. We can now define a universe of classes as follows: U = {tree(c) C is a class in some statically correct program} 11

12 This is a mathematical object on which we later shall observe an interesting structure. 3.4 Examples class Object end Object class A var x: Object end A class B var x: Object method set(y: Object) returns selfclass x := y ; self end B Figure 4: Example classes. We now provide some short examples of the above definitions. Consider the classes A and B in figure 4. Let us first consider what the corresponding trees look like. We shall use the abbreviations L A = var x: L B = var x: method set(y: ) returns x :=y ; self The equation system for the trees is now tree(object) = Ω() tree(a) = L A (tree(object)) tree(b) = L B (tree(object), tree(object), tree(b)) The corresponding trees are pictured in figure 5. We can finally observe that tree(b)[3, 3, 2] = Ω tree(b)[3, 3, 3] = L B 12

13 tree(a) = L A Ω tree(b) = L B Ω Ω L B Ω Ω L B. Ω Ω Figure 5: Example trees. 4 Inheritance Inheritance is reuse of class definitions. It may significantly increase programmer productivity and decrease source code size. In this section we add inheritance to our example language, discuss its properties, and show that we can use the universe of class representations from the previous section to represent also the classes defined by inheritance. 4.1 Syntax To introduce inheritance we extend the grammar in figure 3 as showed in figure 6. (Class) C ::= class ClassId inherits ClassId var D 1... D k M 1... M n end ClassId Figure 6: Syntax of Inheritance. The class name following inherits is called the superclass of the class being defined; the latter is called a subclass of the superclass. The subclass is a modification of the superclass: it may add variables and methods, and if a method name coincides with an existing one, then the new method definition overrides the old one. The body of a new method definition may refer to both the existing variables and the existing methods. It has been argued by Snyder [53] that much better encapsulation is achieved if only the existing methods can be referred; we ignore this consideration in this paper. For a denotational semantics of inheritance, see [16, 48, 31, 17]. 13

14 4.2 Properties Inheritance can be used in various ways, ranging from undisciplined code-grabbing to disciplined program structuring based on a hierarchical design method [21, 3, 14, 30]. Common to all approaches is that the superclass is created before the subclass. We will henceforth use the terminology that the subclass is temporally dependent on its superclass. A class can be a subclass of another class which itself is defined by inheritance. The chain of superclasses is always finite, however, because the program is finite. Also, the superclass chain will contain no cycles; we will say that it is temporally acyclic. Note that any non-empty class can be defined as a subclass of the empty class, which we will call Object. This is actually enforced in Smalltalk. In this situation, the inheritance hierarchy is a tree, otherwise it is a forest. If C is the superclass and D is the subclass, then it is common to say that D is-a C [6, 55]. For example, if Student is a subclass of Person, then it seems reasonable to say that Student is-a Person. It is convenient to let is-a denote the transitive closure of this relation. The other possible relation between classes is has-a. If a class C declares a variable of a type which contains the class D, then we will say that C has-a D. For example, if the Student declares a graduate variable of type Boolean, then Student has-a Boolean. We will also say that C has-a D if C mentions D in a parameter list or as an argument of new or instanceof. Analogously with is-a, we let has-a denote the transitive closure of this relation. It is crucial not to confuse is-a and has-a. If C has-a D and D has-a C, then we will say that C and D are mutually recursive. In comparison, it is impossible to have both C is-a D and D is-a C because that would be a temporal cycle. To make any sense, mutually recursive classes must be defined simultaneously by the programmer. Together, is-a and has-a impose a temporal order on the classes in a program. The intuition is that a class D depends temporally on a class C if C has to be created before D. Formally, we can represent a program as a directed graph. The graph has one node for every class definition in the program. Each node has a label which is the gapped source code of the corresponding implementation. There will be two kinds of edges: is-a and has-a. We have an is-a edge from every subclass to its immediate superclass, and a has-a edge from every gap in the label to the node representing the missing class. We can then define temporal dependency to be a path between two nodes containing at least one is-a edge. A temporal dependency from D to C means that C must be created before D. If the classes in a program contains no temporal cycles, then we will call it wellformed. A well-formed program can be transformed into one which does not use inheritance, as demonstrated below. 14

15 Our reason for doing this transformation is that when all classes are represented as elements of our universe of class representations, then it makes sense to analyze this universe in order to discover other relations between classes besides is-a and has-a. Such relations will be independent both of class names and of the particular shorthands that can be used in program texts. So far, the only shorthand we have encountered is inheritance, but later on we will define another called class substitution. Pedersen [47] proposed the notion of generalization which is the inverse of inheritance. The loss of an explicit class hierarchy may at first seem to cause severe problems, since some programming mechanisms depend on exactly this. In particular, we think about redefinition of method bodies in subclasses, and about the constructs super [25] and inner [33, 37]. However, these mechanisms depend primarily on the existence of multiple implementations of methods. This we can certainly handle, since a label contains a sequence of implementations of methods several of which may have the same name. The dynamic behavior of a message send is to search the label from right to left, and to execute the first implementation of the method that is found. This gives the correct semantics of method redefinitions. The construct super can be viewed as a directive to search from the location of the present method implementation towards the left. Dually, the construct inner directs the search to go from the present location towards the right. This will nearly give the usual semantics, and is certainly in line with the explanation given in [5]. When expanding the inheritance shorthand it is necessary to be careful when encountering recursive occurrences of a class. A class C is recursive if C has-a C. If a class D inherits this class C, then after expansion, all occurrences of C must have been transformed into D. The reason is that a variable of a type which contains C could be assigned to a variable which contains selfclass. Since selfclass always denotes the class it appears in, it will automatically denote D after the expansion. Hence, C must be transformed into D to preserve static correctness. The complications get worse when considering mutually recursive classes; the algorithm in the following subsection gives a detailed solution to the general case. While it is often the natural choice to transform all recursive occurrences during inheritance, one can certainly find program examples where the opposite choice is preferable. However, with our structural equivalence on classes recursive occurrences must be transformed in order to make the subclass statically correct. The problem could be solved by introducing opacity operators on classes, in line with [43]. In this paper we will not explore this aspect further. 15

16 4.3 The Expansion Algorithm We now present the algorithm that expands a program using inheritance into an equivalent one that does not. The idea behind the algorithm is simple: it rewrites the program in the same fashion that a programmer would have to if the class should be written in a language that does not support inheritance. Consider an inheritance specification B inherits A where the classes A and B (except the inherits A part) are represented by the variables A 1 and B 1 in the following minimized regular equation systems: A 1 = L 1 (Ā). A n = L n (Ā) B 1 = K 1 ( B). B m = K m ( B) Then the expanded version of B is represented by the variable Z in the (not necessarily minimized) regular equation system obtained as follows. Form the union of the equation systems for A and B, remove the equations for A 1 and B 1, add the equation Z = L 1 K 1 (Ā, B) and finally rename all occurrences of A 1 and B 1 into Z. class A var x: A end A class B inherits A var y: A var z: B end B Figure 7: Before expansion of inheritance. This process is illustrated by the following simple example. Consider the classes in figure 7. The minimized regular equations are as follows: A 1 = (var x: )(A 1 ) B 1 = (var y: var z: )(B 2, B 1 ) B 2 = (var x: )(B 2 ) 16

17 According to the algorithm, the regular equations for the expanded class are B 2 = (var x: )(B 2 ) Z = (var x: var y: var z: )(Z, B 2, Z) which translates into the class in figure 8. Note how the recursion at x has been captured. class A var x: A end A class B var x: B var y: A var z: B end B Figure 8: After expansion of inheritance. With this expansion algorithm at hand, we can now consider expanding programs where more than one class is defined using inheritance. Given that a program contains no temporal cycles, the classes can be sorted in temporal order and then expanded one by one. For a detailed explanation and examples of this, see [46]. 5 Generalized Subclassing The main purpose of providing an independent notion of classes is to define a generalized, structural notion of subclassing. This arises directly from the application on U of a partial order on general L-trees. 5.1 A Generalized Interpreter In [45] we present a generalization of a naïve Smalltalk interpreter. This interpreter supports inheritance through a method lookup a run-time search for implementations of methods. Our extended interpreter also does a run-time search for arguments to new and instanceof operations. This allows a more general form of code reuse, which we can express through a partial order on classes. In [45] we give a precise description of the run-time environments of the extended interpreter, and we show the following property: if T 1 T 2 holds, then any runtime implementation of T 1 can be extended to yield a run-time implementation 17

18 of T 2. The code reuse that can be expressed through inheritance corresponds to a suborder of. In this section we shall define the partial order and show a number of its formal properties. In the following sections we shall develop a programming mechanism that is complementary to inheritance; as we shall see, their combination realizes all of. 5.2 A Partial Order on Trees Intuitively, the relation imposes three different constraints on subclasses. Each of these reflect that the subclass reuses the implementation of the superclass. the labels may only be extended: this simply means that the subclass can only extend the implementation and not modify existing parts. This also ensures that all early checks will remain satisfied. equal classes must remain equal: this ensures that all subtype checks will remain satisfied; hence, the code of the superclass can only be reused in a manner that preserves static correctness. the recursive structure must be preserved: this is essential for allowing the code to be reused since different code is generated for selfclass and other classes [45]. The partial order is our generalized notion of subclassing, such that if A is the superclass and B is the subclass, then A B. It may seem strange that super is smaller than sub, but this is a common confusion of terminology. Clearly, the subclass has a larger implementation than the superclass; equally clearly, the superclass is more general than the subclass. We choose to retain the usual terminology, while employing the mathematically suggestive ordering. To be able to define formally, we introduce some auxiliary concepts. The first is a simple partial order on L-trees. Definition 5.1: The usual prefix order on finite strings is written as. The partial order T 1 T 2 on L-trees over Σ holds exactly when α T 1 : α T 2 α T 1 : T 1 [α] T 2 [α] 18

19 Note that is the node-wise extension of. The order reflects that labels may only be extended. We next provide a simple, finite representation of an L-tree. Proposition 5.2: Every L-tree T can be represented by a finite, partial, deterministic automaton with labeled states, with language {α α T }, and where α is accepted in a state labeled T [α]. Proof: The finitely many different subtrees all become accept states with the label of their root. The transitions of the automaton are determined by the fanout from the corresponding root. These automata provide finite representations of L-trees. The idea of representing a regular tree as an automaton is also exploited in [51, 52]. All later algorithms will in reality work on such automata. Proposition 5.3: The partial order is decidable. Proof: The algorithm is a variation of the standard one for language inclusion on the corresponding automata. The second auxiliary concept is the notion of a generator for an L-tree. Definition 5.4: If T is an L-tree over Σ, then its generator gen(t ) is another L-tree which is obtained from T by replacing all maximal, proper occurrences of T itself by a singleton tree with the special label ; it is assumed that is incomparable with all other labels in the -ordering. We say that T is recursive when T gen(t ). Note that the generator itself may be an infinite tree, and that the original tree can readily be recovered from its generator. The generator of a class makes explicit all the recursive occurrences of the class itself. For example, all occurrences of selfclass in its source code are replaced by, but also mutual recursion is captured. 19

20 We are now ready to define using the order which is a subset of. Definition 5.5: The relation T 1 T 2 on L-trees is the largest subset of such that the following stability condition holds α, β T 1 : T 1 α = T 1 β T 2 α = T 2 β The relation T 1 T 2 on L-trees holds exactly when α T 1 : gen(t 1 α) gen(t 2 α) Note that if T 1 T 2 then for any α T 1 we also have T 1 α T 2 α. Since is a subset of, it reflects that labels may only be extended. Furthermore, the stability condition ensures that equal classes remain equal. The relation is then defined so that the generators at all levels are in the relation. This ensures that the recursive structure is preserved. Proposition 5.6: The relations and are decidable, partial orders. Proof: Clearly, is a partial order since stability is reflexive and transitive; also, is a partial order because is. Since by proposition 5.3 we know that is decidable, we must only show that stability is, too. On minimized automata, representing the trees T 1 and T 2, stability translates to the property that any two words α, β accepted in the same state by the T 1 -automata must also be accepted in the same state by the T 2 - automata. This property can be decided for general automata using a simple, linear-time dynamic programming algorithm. To decide we can rely on decidability of and the fact that L-trees have only finitely many different subtrees, all of which can easily be constructed. 5.3 Properties The subclassing order has the same characteristic properties as inheritance: it has a least element, has finite intervals, does not allow temporal cycles, and preserves subtyping. In this subsection we prove these claims. Proposition 5.7: The partial order has a least element. 20

21 Proof: Clearly, is just the singleton tree with the label Ω. In a class hierarchy, corresponds to the empty class Object. To show that has finite intervals, we need a notion of unfolding directed graphs. Definition 5.8: Let G be a directed, rooted graph containing a path from the root to each vertex. A particular unfolding of G, called unfold(g), is obtained by the following variation of the standard depth-first search algorithm [1] starting in the root. The modification is that if the current edge leads to a previously visited vertex in a different strongly connected component, then a fresh copy of that entire component is inserted in the graph. See for example figure 9, where (v 1, v 3 ) is the current edge. The graph unfold(g) can be understood as a tree of possibly multiple copies of the strongly connected components of G. v 1 v 2 v 1 v 2 v 3 v 4 v 3 v 4 v 2 v 3 Figure 9: A step in the construction of unfold(g). Lemma 5.9: A depth-first traversal of unfold(g) has the property that if the current edge leads to a previously visited vertex, then that vertex is on a cycle of already processed edges and the current edge. Proof: Let (v, w) be the current edge. If we have previously visited w, then, by construction of unfold(g), v and w are in the same strongly connected component. Because of the depth-first strategy, there is a path of already processed 21

22 edges from w to v. The result follows. Proposition 5.10: For any L-tree T 2 the interval {T 1 T 1 T 2 } is finite. Proof: For the purposes of this proof, we shall represent L-trees by their canonical automata. This is obtained by subjecting the minimal automaton to the unfolding described in definition 5.8. Clearly, this new automaton will have the same language and represent the same L-tree; in particular, the L-tree can be recovered from the automaton. Now, assume that T 1 T 2. Let A 1 and A 2 be their canonical automata. We shall construct a total function h from states of A 1 to states of A 2 with the following properties h maps the initial state of A 1 to that of A 2 if x i y is a transition in A 1, then h(x) i h(y) is a transition in A 2 the label of x is that of h(x) h is injective The construction works iteratively through a depth-first traversal of A 1. At any stage the current h will satisfy all of the above properties, but it may be partial. We start with just the pair of initial states, which is clearly legal. We proceed by examining the current unexplored depth-first A 1 -transition x i y from a state x in the domain of h. This is matched by an A 2 -transition h(x) i z, since the label of x is than that of h(x). The function h is now extended to h = h {y z}. Only two necessary properties are not immediate: that h is still a function, and that h is still injective. Assume that we have already seen y before; we must assure that z = h(y). Having seen y before means, from lemma 5.9, that we have a cycle from y to y. Now look at the generator of the subtree of T 1 that corresponds to y. The cycle that we have traversed is here a path from the root to a -label. In the h(y)-generator of T 2 the same path must also lead to a -label, since no other label can satisfy the -requirement. Hence, the path from y to y in A 1 translates to a path from h(y) to h(y) in A 2. It follows that z = h(y). Similarly, injectivity follows. If for some x we have z = h(x ), then the cycle from z to z in A 2 must correspond to a cycle in A 1, from which it follows that x = x. Since all states in a canonical automaton can be reached from the initial state, this construction will terminate with a total function. 22

23 To proceed, we observe that the existence of any injective function from states of A 1 to states of A 2 assures that there are no more states in A 1 than in A 2. Since any label in A 1 must be than some label in A 2, and we know that has finite intervals, then any A 1 must be built out of a bounded number of states and a finite set of labels. For simple combinatorial reasons, there can only be finitely many such automata. Since different L-trees yield different canonical automata, the result follows. In particular, this result means that any class can only have finitely many superclasses. Corollary 5.11: For any two L-trees T 1, T 2 the closed interval {S T 1 S T 2 } is finite. Proof: This is just a subset of the finite interval in proposition Next, we can show that our generalized notion of subclassing does not allow any temporal cycles. Since in our framework and T 1 has-a T 2 iff α : T 1 α = T 2 T 1 is-a T 2 iff T 2 T 1 T 2 T 1 then, to eliminate temporal cycles of the form T has-a S is-a T, we must show that no tree can be strictly -less than one of its subtrees. Longer cycles are handled by transitivity and essentially the same argument. T S S S Figure 10: A temporal cycle. Theorem 5.12: Let T by an L-tree and let S be a subtree of T. If T S, then 23

24 T = S. Proof: Suppose T S and T S. Choose α so that T α is a maximal occurrence of S in T. Let S = S α. Then S S, as illustrated in figure 10. We will now show that S S. Suppose S = S. There are two cases. First, if the generator of S has a -label in position α, then also T has a -label in position α. This implies T = S, a contradiction. Second, if the generator of S does not have a -label in position α, then we can find a maximal proper occurrence of S in S. Let this occurrence be in position β, where β is a proper prefix of α. Thus, the generator of S has a -label in position β, so also T has a -label in position β. Suppose α = βγ. Clearly, T γ = S, contradicting that T α is a maximal occurrence of S in T. We have thus proved that S S. By iterating the above construction we obtain a strictly -increasing chain T T α T α 2 α 3 T α i This means that T has infinitely many different subtrees, contradicting its being an L-tree. A final property can be phrased as the slogan subclassing preserves subtyping. Intuitively, this means that subtype relationships will be preserved in subclasses. Proposition 5.13: A type expression in a class T consists of, say, n classes located as the subtrees at addresses α 1, α 2,..., α n ; that is, the expression denotes the set A = {T α 1, T α 2,..., T α n } Suppose also we have another type expression denoting the set B = {T β 1, T β 2,..., T β m } and that the inclusion A B holds. Let S be any subclass of T. We then have two corresponding sets A = {S α 1, S α 2,..., S α n } B = {S β 1, S β 2,..., S β m } and we are guaranteed that the inclusion A B will also hold. Proof: This follows immediately from the stability requirement on. 5.4 Examples To illustrate the concepts introduced in this section we continue the example from subsection

25 1 L A Ω Ω 1, 2 L B 3 Figure 11: Example automata. class C var h: B var t: selfclass end C class D inherits C var z: Object end D Figure 12: Example classes. The automata corresponding to the classes A and B are shown in figure 11. We can also observe that tree(a) tree(b). We next program two new classes C and D shown in figure 12. As before, we define L C = var h: var t: L D = var z: The corresponding trees, shown in figure 13, are defined by the equations tree(c) = L C (tree(b), tree(c)) tree(d) = L C L D (tree(b), tree(d), tree(object)) Let us show that tree(c) tree(d). We have three different situations where a generator in tree(c) must be than a similar generator in tree(d). Examples of all three situations are shown in figure 14. A tree that is than tree(d) but not is shown in figure 15; it is not recursive, while tree(d) is. 25

26 tree(c) = L C L B L C Ω Ω... tree(d) = L B Ω Ω. L C L D L C L D.. Ω Ω Figure 13: Example trees. gen(tree(c)) = L B Ω Ω. L C L C L D gen(tree(d)) = L B Ω Ω Ω. gen(tree(c) 1) = L B Ω Ω gen(tree(d) 1) = L B Ω Ω gen(tree(c) 1, 2) = Ω gen(tree(d) 1, 2) = Ω Figure 14: Relating generators. 6 The Orthogonality Result Inheritance is a programming mechanism which can realize only part of ; more precisely, it captures a suborder. 6.1 Two Suborders Definition 6.1: The partial order T 1 I T 2 holds exactly when T 1 T 2 α T 1 : T 1 α T 1 T 1 [α]=t 2 [α] 26

27 L C L B L C Ω Ω Ω Ω Ω Figure 15: A non-recursive tree. This states that only the root label and its recursive occurrences may change. The I -part of is just inheritance. Proposition 6.2: If C 1 is inherited by C 2 in any program, then tree(c 1 ) I tree(c 2 ). Conversely, if T 1 I T 2 then any C 1 such that tree(c 1 ) = T 1 can be modified by inheritance to yield a C 2 such that tree(c 2 ) = T 2. Proof: Consider the isomorphism between L-trees and minimal equation systems. It is quite easy to see that I in this framework exactly captures the constructions performed by the expansion algorithm. The remaining part of can be characterized in a satisfying manner: as an orthogonal complement of I, in the following sense. Definition 6.3: Let P be a partial order on a set S. We use the notation (S) for the diagonal {(s, s) s S}, and the notation A for the reflexive, transitive closure of a relation A. We write Q P R, if Q and R are partial orders such that Q R = (S) and (Q R) = P. We call Q, R an orthogonal basis for P when Q P R Q P R Q Q Q P R R R 27

28 This generalizes the notion of basis in [26]. For example, if (S 1, 1 ) and (S 2, 2 ) are partial orders, then 1 (S 2 ) and (S 1 ) 2 form an orthogonal basis for 1 2. The remaining part of can be captured by the following suborder. Definition 6.4: The partial order T 1 S T 2 holds exactly when T 1 T 2 T 1 [λ]=t 2 [λ] This states that the root label must remain unchanged. 6.2 Orthogonality We can now show that I, S is an orthogonal basis for. This result is important, since it allows us to simply search for a programming mechanism that relates to S in the same fashion that inheritance relates to I ; the less appealing choice was to find a mechanism directly for the awkward set difference of and I. Furthermore, when we have such a S -mechanism, then it is orthogonal to inheritance in a formal sense. The next chapter discloses that S yields a form of genericity. We have thus shown that inheritance and genericity are independent, orthogonal components of generalized subclassing. To prove the result we need a series of lemmas. Lemma 6.5: The relations I, S are both partial orders, and I S = (U). Proof: Clearly, S is a partial order. The extra condition on T 1 I T 2 simply means that for every α gen(t 1 ) we have gen(t 1 )[α] = gen(t 2 )[α], except for the root labels which are -related. Hence, I is a partial order. If also T 1 S T 2 then all labels must be equal, so the generators, and the trees, are equal. Lemma 6.6: Whenever T 1 T 2 then there is a unique A U such that T 1 S A I T 2. Proof: Suppose T 1 T 2. Then gen(t 1 ) gen(t 2 ). Let L 1 be the root label of gen(t 1 ). Then the root label of gen(t 2 ) must look like L 1 L 2. Let gen(a) be obtained from gen(t 2 ) by removing the L 2 -part of the root label and the subtrees that correspond to its gaps. Since subtrees with the same address in -related trees also will be -related, it follows that T 1 A. Since T 1, T 2 U, then clearly A U. But since they both have root label L 1, we also have T 1 S A. It is trivially the case that A I T 2, so we have shown that T 1 S A I T 2. 28

29 For the uniqueness of A, suppose we also have T 1 S B I T 2. Then for every α gen(t 2 ) we have gen(t 2 )[α] = gen(a)[α] = gen(b)[α], except for the root labels; but we also have T 1 [λ] = A[λ] = B[λ], so A = B. Lemma 6.7: ( I S ) = Proof: Immediate from lemma 6.6. Lemma 6.8: No partial order M which is a proper subset of S satisfies ( I M ) =. Also, no partial order N which is a proper subset of I satisfies ( N S ) =. Proof: Suppose we have such a M. Choose (x, y) S \ M. Then x[λ] = y[λ], so no I \ (U) steps can take place on a path from x to y. Hence, (x, y) M = M, which is a contradiction. The other half of the result is proved similarly. Lemma 6.9: Let P be a partial order, where all closed intervals are finite. Whenever P 1, P 2 P and P1 = P 2 = P, then (P 1 P 2 ) = P. Proof: Clearly, (P 1 P 2 ) P. For the opposite inclusion, suppose (x, y) P. The proof is by induction in the size of the open interval over P from x to y. If the interval is empty, then either (x, y) (P 1 P 2 ) 0, or (x, y) (P 1 P 2 ). Now, suppose the interval contains n + 1 elements. Choose z in it. Then both the open interval from x to z and that from z to y contain at most n elements. Hence, by the induction hypothesis, (x, z), (z, y) (P 1 P 2 ). By transitivity of (P 1 P 2 ) we conclude (x, y) (P 1 P 2 ). Lemma 6.10: If M S then I M. Also, if I N then S N. Proof: Suppose M S. By corollary 5.11, all closed -intervals of U are finite, so by lemmas 6.7 and 6.9, = (( I S ) ( M S )) = (( I M ) S ). By lemma 6.8, I M cannot be a proper subset of I. Hence, I M = I, so I M. The other half of the lemma is proved similarly. Theorem 6.11: I, S is an orthogonal basis for. Proof: Combine lemmas 6.5, 6.7, and The significance of this result is that a programming mechanism realizing S, together with inheritance which realizes I, allow the programming of all subclasses. Furthermore, two such programming mechanisms would be completely non-redundant; neither could emulate the other. The situation is illustrated in 29