Practical Common Lisp

Methods that explicitly specialize more than one of the generic function's required parameters are called multimethods. Multimethods are where generic functions and message passing really part ways. Multimethods don't fit into message-passing languages because they don't belong to a particular class; instead, each multimethod defines a part of the implementations of a given generic function that applies when the generic function is invoked with arguments that match all the method's specialized parameters.

Multimethods vs. Method Overloading

Programmers used to statically typed message-passing languages such as Java and C++ may think multimethods sound similar to a feature of those languages called method overloading. However, these two language features are actually quite different since overloaded methods are chosen at compile time, based on the compile-time type of the arguments, not at runtime. To see how this works, consider the following two Java classes: public class A { public void foo(A a) { System.out.println("A/A"); } public void foo(B b) { System.out.println("A/B"); } } public class B extends A { public void foo(A a) { System.out.println("B/A"); } public void foo(B b) { System.out.println("B/B"); } } Now consider what happens when you run the main method from this class. public class Main { public static void main(String[] argv) { A obj = argv[0].equals("A") ? new A() : new B(); obj.foo(obj); } } When you tell Main to instantiate an A, it prints "A/A" as you'd probably expect. bash$ java com.gigamonkeys.Main A A/A However, if you tell Main to instantiate a B, then the true type of obj is taken into account for only half the dispatching. bash$ java com.gigamonkeys.Main B B/A If overloaded methods worked like Common Lisp's multimethods, then that would print "B/B" instead. It is possible to implement multiple dispatch by hand in message-passing languages, but this runs against the grain of the message-passing model since the code in a multiply dispatched method doesn't belong to any one class.

Multimethods are perfect for all those situations where, in a message-passing language, you struggle to decide to which class a certain behavior ought to belong. Is the sound a drum makes when it's hit with a drumstick a function of what kind of drum it is or what kind of stick you use to hit it? Both, of course. To model this situation in Common Lisp, you simply define a generic function beat that takes two arguments.

(defgeneric beat (drum stick)

(:documentation

"Produce a sound by hitting the given drum with the given stick."))

Then you can define various multimethods to implement beat for the combinations you care about. For example:

(defmethod beat ((drum snare-drum) (stick wooden-drumstick)) ...)

(defmethod beat ((drum snare-drum) (stick brush)) ...)

(defmethod beat ((drum snare-drum) (stick soft-mallet)) ...)

(defmethod beat ((drum tom-tom) (stick wooden-drumstick)) ...)

(defmethod beat ((drum tom-tom) (stick brush)) ...)

(defmethod beat ((drum tom-tom) (stick soft-mallet)) ...)

Multimethods don't help with the combinatorial explosion—if you need to model five kinds of drums and six kinds of sticks, and every combination makes a different sound, there's no way around it; you need thirty different methods to implement all the combinations, with or without multimethods. What multimethods do save you from is having to write a bunch of dispatching code by letting you use the same built-in polymorphic dispatching that's so useful when dealing with methods specialized on a single parameter.[180]

Multimethods also save you from having to tightly couple one set of classes with the other. In the drum/stick example, nothing requires the implementation of the drum classes to know about the various classes of drumstick, and nothing requires the drumstick classes to know anything about the various classes of drum. The multimethods connect the otherwise independent classes to describe their joint behavior without requiring any cooperation from the classes themselves.

To Be Continued . . .

I've covered the basics—and a bit beyond—of generic functions, the verbs of Common Lisp's object system. In the next chapter I'll show you how to define your own classes.

17. Object Reorientation: Classes

If generic functions are the verbs of the object system, classes are the nouns. As I mentioned in the previous chapter, all values in a Common Lisp program are instances of some class. Furthermore, all classes are organized into a single hierarchy rooted at the class T.

The class hierarchy consists of two major families of classes, built-in and user-defined classes. Classes that represent the data types you've been learning about up until now, classes such as INTEGER, STRING, and LIST, are all built-in. They live in their own section of the class hierarchy, arranged into appropriate sub- and superclass relationships, and are manipulated by the functions I've been discussing for much of the book up until now. You can't subclass these classes, but, as you saw in the previous chapter, you can define methods that specialize on them, effectively extending the behavior of those classes.[181]

But when you want to create new nouns—for instance, the classes used in the previous chapter for representing bank accounts—you need to define your own classes. That's the subject of this chapter.

DEFCLASS

You create user-defined classes with the DEFCLASS macro. Because behaviors are associated with a class by defining generic functions and methods specialized on the class, DEFCLASS is responsible only for defining the class as a data type.

The three facets of the class as a data type are its name, its relation to other classes, and the names of the slots that make up instances of the class.[182] The basic form of a DEFCLASS is quite simple.

(defclass name (direct-superclass-name*)

(slot-specifier*))

What Are "User-Defined Classes"?

The term user-defined classes isn't a term from the language standard—technically what I'm talking about when I say user-defined classes are classes that subclass STANDARD-OBJECT and whose metaclass is STANDARD-CLASS. But since I'm not going to talk about the ways you can define classes that don't subclass STANDARD-OBJECT and whose metaclass isn't STANDARD-CLASS, you don't really have to worry about that. User-defined isn't a perfect term for these classes since the implementation may define certain classes the same way. However, to call them standard classes would be even more confusing since the built-in classes, such as INTEGER and STRING, are just as standard, if not more so, because they're defined by the language standard but they don't extend STANDARD-OBJECT. To further complicate matters, it's also possible for users to define new classes that don't subclass STANDARD-OBJECT. In particular, the macro DEFSTRUCT also defines new classes. But that's largely for backward compatibility—DEFSTRUCT predated CLOS and was retrofitted to define classes when CLOS was integrated into the language. But the classes it creates are fairly limited compared to DEFCLASSed classes. So in this chapter I'll be discussing only classes defined with DEFCLASS that use the default metaclass of STANDARD-CLASS, and I'll refer to them as user-defined for lack of a better term.

180

In languages without multimethods, you must write dispatching code yourself to implement behavior that depends on the class of more than one object. The purpose of the popular Visitor design pattern is to structure a series of singly dispatched method calls so as to provide multiple dispatch. However, it requires one set of classes to know about the other. The Visitor pattern also quickly bogs down in a combinatorial explosion of dispatching methods if it's used to dispatch on more than two objects.

181

Defining new methods for an existing class may seem strange to folks used to statically typed languages such as C++ and Java in which all the methods of a class must be defined as part of the class definition. But programmers with experience in dynamically typed object-oriented languages such as Smalltalk and Objective C will find nothing strange about adding new behaviors to existing classes.

182

In other object-oriented languages, slots might be called fields, member variables, or attributes.