I mostly liked this article to show some of the basic features of CLOS, but was a little disappointed about the attitude toward the end. The attitude toward some of the more advanced features of CLOS like method combination reminds me of the attitude that some people have for functional programming. "Well, it's cool you can 'map' and 'reduce' a function across a list, but why not just use a for-loop?" I think most people on HN can see why that may not be a good attitude to have because of the larger implications of functional programming.

Method combination has an overarching theory behind it. My take is as follows: Methods are by definition associated with a set of constraints on the arguments. The constraints are, for the most part, specified by their class. Because classes form a mathematical lattice, we have the notion of "more and less specifically applicable methods" for a set of arguments, and so the aforementioned constraints can be ordered and usually the most specific method is called, as the article explains. But the key thing to notice here is that if we remove the notion of "more or less applicable", and replace it with just the notion of "applicable", then we can do some interesting things.

For a particular generic function (Lisp parlance for a method with unspecified constraints), and for a given set of arguments to the function, there is a set of applicable methods. How we arrange to execute these applicable methods, and how we arrange to use the results of the executions, is what constitutes method combination.

There are two trivial ways to arrange what gets executed. The popular way is to just execute the most specific only. The other trivial way is to just execute everything. Many kinds of non-default method combinations (like the LIST method combination) do this. Another one, which I find generally more useful, is the + method combination. (This sums all of the results of the applicable methods. One usual example is calculating prices with additive taxes.)

Many problems can be decomposed into one which sounds like the following: 1. Classify your objects into a (multiple-inheritance) class hierarchy. 2. Write down the behavior that is applicable to products of these objects.

If you can do 1 & 2, then these aspects of CLOS and method combination can solve your problem in a clean way.

* * *

There were a few nits I had with the article otherwise. What he calls "forms" are not forms. "Forms" are memory representations of the syntax. The syntax is called "symbolic expressions" or "S-expressions" or "S-exprs". An even more pedantic nit is that IF is not called a "special form", it is called a "special operator". The combination of a special operator and its arguments make a "special form". (But who cares. Even seasoned Lispers say "special form" for operators.)