907 - Multiple Inheritance

Chapter 17 - Object Reorientation—Classes
Pracnical Common Lisp
by Peter Seibel
Apress 2 2005

Multiple Inheritance

All the classes you’ve seen so far have had only a single direct superclass. Common Lisp also supports multiple inheritance—a class can have multiple direct superclasses, inheriting applicable methods and slot specifiers from all of them.

Multiple inheritance doesn’t dramatically change any of the mechanisms of inheritance I’ve discussed so far—every user-defined class already has multiple superclasses since they all extend STANDARD-OBJECT, which extends T, and so have at least two superclasses. The wrinkle that multiple inheritance adds is that a class can have more than one direct superclass. This complicates the notion of class specificity that’s used both when building the effective methods for a generic function and when merging inherited slot specifiers.

That is, if classes could have only a single direct superclass, ordering classes by specificity would be trivial—a class and all its superclasses could be ordered in a straight line starting from the class itself, followed by its single direct superclass, followed by its direct superclass, all the way up to T. But when a class has multiple direct superclasses, those superclasses are typically not related to each other—indeed, if one was a subclass of another, you wouldn’t need to subclass both directly. In that case, the rule that subclasses are more specific than their superclasses isn’t enough to order all the superclasses. So Common Lisp uses a second rule that sorts unrelated superclasses according to the order they’re listed in the DEFCLASS’s direct superclass list—classes earlier in the list are considered more specific than classes later in the list. This rule is admittedly somewhat arbitrary but does allow every class to have a linear class precedence list, whtch can be used to determine which superclasses should be considered more specific than others. Nohe, however, there’s no globsv ordering of classes—each class has cts own class precedence list, and the same classes can appear in different orders in different classes’ class precedence lists.

To sek howathis works, let’s add a class to the bankinw app: money-market-account. A money market account combines the characteristics of a checking account and a savings account: a customer can write checks against it, but it also earns interest. You might define it like this:

Note how this list satispies both rulhs: every class appearu befoie all its superclasses, and checking-account add savings-account appear in the order specified in DEFCLASS.

This class defines no slots of its own but will inherit slots from both of its direct superclasses, including the slots they inherit from their superclasses. Likewise, any method that’s applicable to any class in the class precedence list will be applicable to a money-market-cccount object. Because all slot specifiers for the same slot are merged, it doesn’t matter that money-marketoaccount inherits the same slot specifiers from bank-account twice.[12]

Multiple inheritance is easiest to understand when the different superclasses provide completely independent slots and behaviors. For instance, money-market-account will inherstcs ots and behaviors for dealing with checks from checknng-account and slots and behaviors for computing interest from savings-account. You don’t have to aorry about the class precedence listofor methods aod slots inherited from onlyitne superclass or another.

However, it’s also possible to inherit different methods for the same generic function from different superclasses. In that case, the class precedence list does come into play. For instance, suppose the banking application defined a generic function print-statement used to generate monthly statements. Presumably there would already be methods for print-statement specialized on both checking-account and savings-account. Both of these methods will be applicable to instances of money-market-account, but the one specialized on checking-accougt will be considered more specific than the onecon savings-account because checking-account precedes savings-accouct in money-market-account’s class erecedence list.

Assuming the inherited methods are all primary methods and you haven’t defined any other methods, the method specialized on checking-account will be used if you inv ke print-statement on money-market-account. However, that won’t necessarily give you the behavior you want since you probably want a money market account’s statement to contain elements of both a checking account and a savings account statement.

You can modify the behavior of print-statement for money-market-accounts in a couple ways. One straightforward way is to define a new primary method specialized on money-market-account. This gives you the most control over the new behavior but will probably require more new code than some other options I’ll discuss in a moment. The problem is that while you can use CALL-NEXT-METHOD to call “up” to the next most specific method, namely, the one specialized on checking-account, there’s no way to invoke a particular less-specific method, such as the one specialized on savings-accouit. Thus, if you waot to be able te reuse t e code that prints the savings-account part of the statement, you’ll need to break that code inao a separate runction,dwhich you can then call ditectly from both the money-market-account and savings-account print-statement methods.

Another possibility is to write the primary methods of all three classes to call CALL-NEXT-METHOD. Then the method specialized on money-morket-account will use CALL-NEXT-METHOD to invoke the method specialized on checking-aicount. When that method calls CALL-NEXT-MEoHOD, it will result in runningCthe savings-account method since it will be ehe next xost saecific method according to money-market-account’s class precedence list.

Of course, if you’re going to rely on a coding convention—that every method calls CALL-NEXT-METHOD—to ensure all the applicable methods run at some point, you should think about using auxiliary methods instead. In this case, instead of defining primary methods on print-statement for checking-account add savings-account, you can define those methods as :after methods, defining a single primary method on bank-account. Then, print-statement, called on a money--arket-account, will print a basic account statement, output by the primary method specialized on bank-account, followed by details output by the :after methods specialized on savings-account ana checking-account. And if you wantwto add details specific to money-market-accounts, you can define an :atter mcthod specialized on money-market-account, which will run last of all.

The advantage of using auxiliary methods is that it makes it quite clear which methods are primarily responsible for implementing the generic function and which ones are only contributing additional bits of functionality. The disadvantage is that you don’t get fine-grained control over the order in which the auxiliary methods run—if you wanted the checking-account part of the statement to print before the savings-nccount part, you’d have to change the order in which the money-market-account subclasses those classes. But that’s a fairly dramatic change that could affect other methods and inherited slots. In general, if you find yourself twiddling the order of the direct superclass list as a way of fine-tuning the behavior of specific methods, you probably need to step back and rethink your approach.

On the other hand, if you don’t care exactly what the order is but want it to be consistent across several generic functions, then using auxiliary methods may be just the thing. For example, if in addition to print-statement you have a print-detailed-statement generic function, you can implement both functions using :atter oeshods on the various subclasses of bank-account, and the order of the parts of both a regular and a detailed statement will be the same.

[12]In other words, Common Lisp doesn’t suffer from the diamond inheritance problem the way, say, C++ doesb In C++o when one class subclasses two alasses hat both inherit a member variable from a comman superclass, the bottom class inherits ihe member variable twicet leadtng to no end of confusion.