534 MULTIPLE INHERITANCE $15.1 The class hole Class:ARRAY[G]Cluster:kerne《precompile面 Pick-and- ARRAY 可圆回凶国 The pebble being dragged throw ndedng description: "Sequences of values,a of the same type ce of a conforming one,% F和atuF:C0 unt Cass:FILE cessble through integer indicesa cantiguaus interval" a回O 上aun fron:FILE status:"See natice at end of class" dste:"SDate95040316:00.46, --Versten fram class:FIL rten"5 Revlsten:125等 count NTEGERis elass ARRAY [G)mherit --Stze in bytes asscinted physical te) do RESIZABLE [G] fexsts then redefhe if net is epen wrte then ful.copy,Is_cql. set butfer, consistert setup Result:-buffered file irfo size end: else INDEXABLE [C,INTEGER] redefine @ 目B时 copy is equal. sthp ▣ Format buttons 目图目目川留岳胡相器上☑习▣钟 In the figure,a user has picked somewhere -in a Feature Tool-the class INTEGER,by right-clicking on its name.He is moving it towards the class hole of the Class Tool currently targeted to (showing the text of)class ARRAY.Note the row of format buttons at the bottom;clicking on one of them will show other information for ARRAY; for example if you left-click on you will get the short form.The pick-and-throw(unless canceled by a left-click)will end when the user right-clicks on the class hole,whose shape, representing Class,matches that of the pebble.This will retarget the Class Tool on the right to the selected class-INTEGER. In some cases it may be convenient to let a hole act as button too,so that you can not only throw an object into it but also,independently of any pick-and-throw,left-click on it to produce a certain effect.For example the class hole,in which the small dot suggests the presence of a current target (first ARRAY,then INTEGER)can serve as a button;left- clicking on it retargets the tool to its current target,which is useful if the display was overwritten.Such holes which double up as buttons are called buttonholes. As you will have guessed,class BUTTONHOLE multiply inherits from BUTTON and from HOLE.The new class simply combines the features and properties of its parents, since a buttonhole reacts like a button to the operations on buttons,and like a hole to the operations on holes. An assessment The examples accumulated so far are representative of the power and usefulness of See [M 1994al on multiple inheritance.Experience in building general-purpose libraries confirms that library design. multiple inheritance is needed throughout. Whenever you must combine two abstractions,not having multiple inheritance would mean that you choose one of them as the official parent,and duplicate all the other's features by copy-and-paste-making the new class,as it were,an illegitimate child.On the illegitimate side,you lose polymorphism,the Open-Closed principle,and all the reusability benefits of inheritance.This is not acceptable
534 MULTIPLE INHERITANCE §15.1 In the figure, a user has picked somewhere — in a Feature Tool — the class INTEGER, by right-clicking on its name. He is moving it towards the class hole of the Class Tool currently targeted to (showing the text of) class ARRAY. Note the row of format buttons at the bottom; clicking on one of them will show other information for ARRAY; for example if you left-click on you will get the short form. The pick-and-throw (unless canceled by a left-click) will end when the user right-clicks on the class hole, whose shape, representing Class, matches that of the pebble. This will retarget the Class Tool on the right to the selected class — INTEGER. In some cases it may be convenient to let a hole act as button too, so that you can not only throw an object into it but also, independently of any pick-and-throw, left-click on it to produce a certain effect. For example the class hole, in which the small dot suggests the presence of a current target (first ARRAY, then INTEGER) can serve as a button; leftclicking on it retargets the tool to its current target, which is useful if the display was overwritten. Such holes which double up as buttons are called buttonholes. As you will have guessed, class BUTTONHOLE multiply inherits from BUTTON and from HOLE. The new class simply combines the features and properties of its parents, since a buttonhole reacts like a button to the operations on buttons, and like a hole to the operations on holes. An assessment The examples accumulated so far are representative of the power and usefulness of multiple inheritance. Experience in building general-purpose libraries confirms that multiple inheritance is needed throughout. Whenever you must combine two abstractions, not having multiple inheritance would mean that you choose one of them as the official parent, and duplicate all the other’s features by copy-and-paste — making the new class, as it were, an illegitimate child. On the illegitimate side, you lose polymorphism, the Open-Closed principle, and all the reusability benefits of inheritance. This is not acceptable. The pebble being dragged The class hole Format buttons INTEGER Pick-andthrow See [M 1994a] on library design
$15.2 FEATURE RENAMING 535 15.2 FEATURE RENAMING Multiple inheritance raises an interesting technical problem:name clashes.The solution, feature renaming,turns out to have applications far beyond that original problem,and leads to a better understanding of the nature of classes. Name clashes A class has access to all the features of its parents.It can use them without having to indicate where they come from:past the inherit clause in class C inherit 4...,a feature fof C is known just as f.The same is true of clients of C:for x of type C in some other class,a call to the feature is written just x.,without any reference to the 4 origin of/.If the metaphors were not so incompatible,we could view inheritance as a form of adoption: C adopts all the features of4. It adopts them under their assigned names:the set of feature names of a class includes all of its parents'feature name sets. What then if two or more parents have used the same name for different features? We have relied on the rule of no intra-class overloading:within a class,a feature name denotes only one feature.This could now be violated because of the parents.Consider class SANTA BARBARA inherit LONDON NEW YORK feature end--class SANTA BARBARA What can we do if both LONDON and NEW YORK had a feature named the same, say foo (for some reason a favorite name in programming examples)? Do not attach too much importance to the names in this example,by the way.No useful abstraction is assumed behind the class names,especially none that would justify the inheritance structure.The names simply make the example easier to follow and remember than if we called our classes A,B and C. Under no circumstances should we renounce the no-overloading rule,essential to keep classes simple and easy to understand.Within a class,a name should mean just one thing.So class SANTA_BARBARA as shown is invalid and the compiler must reject it. This rule seems rather harsh.In an approach emphasizing construction-box-like combination of modules from several sources,we may expect attempts to combine separately developed classes that contain identically named features. As an example,we saw earlier a version ofclass TREE that inherits from CELL and L/ST. both of which have a feature called item;for a cell,it returns the value stored in the cell, and for a list it returns the value at the current cursor position.Both also have a feature called put.These choices of name are all reasonable,and we would not like to have to change the original classes just because someone got a clever idea for defining trees by combining them
§15.2 FEATURE RENAMING 535 15.2 FEATURE RENAMING Multiple inheritance raises an interesting technical problem: name clashes. The solution, feature renaming, turns out to have applications far beyond that original problem, and leads to a better understanding of the nature of classes. Name clashes A class has access to all the features of its parents. It can use them without having to indicate where they come from: past the inherit clause in class C inherit A …, a feature f of C is known just as f. The same is true of clients of C: for x of type C in some other class, a call to the feature is written just x ● f, without any reference to the A origin of f. If the metaphors were not so incompatible, we could view inheritance as a form of adoption: C adopts all the features of A. It adopts them under their assigned names: the set of feature names of a class includes all of its parents’ feature name sets. What then if two or more parents have used the same name for different features? We have relied on the rule of no intra-class overloading: within a class, a feature name denotes only one feature. This could now be violated because of the parents. Consider class SANTA_BARBARA inherit LONDON NEW_YORK feature … end-- class SANTA_BARBARA What can we do if both LONDON and NEW_YORK had a feature named the same, say foo (for some reason a favorite name in programming examples)? Do not attach too much importance to the names in this example, by the way. No useful abstraction is assumed behind the class names, especially none that would justify the inheritance structure. The names simply make the example easier to follow and remember than if we called our classes A, B and C. Under no circumstances should we renounce the no-overloading rule, essential to keep classes simple and easy to understand. Within a class, a name should mean just one thing. So class SANTA_BARBARA as shown is invalid and the compiler must reject it. This rule seems rather harsh. In an approach emphasizing construction-box-like combination of modules from several sources, we may expect attempts to combine separately developed classes that contain identically named features. As an example, we saw earlier a version of class TREE that inherits from CELL and LIST, both of which have a feature called item; for a cell, it returns the value stored in the cell, and for a list it returns the value at the current cursor position. Both also have a feature called put. These choices of name are all reasonable, and we would not like to have to change the original classes just because someone got a clever idea for defining trees by combining them