Advantages of CLOS over other class-based OO systems

Question

I've come across claims that Common Lisp Object System (CLOS) is superior to traditional (class-based) Object-Oriented systems. Wikipedia entry for CLOS mentions differences between the two approaches - mainly multiple dispatch and the separation of classes and methods in CLOS. Are these merely differences or true advantages of CLOS?

Wellfavored

Answer 1

Depends on what you see as advantage.

First CLOS is a class-based object system, compared to non-class-based prototype-oriented object systems. CLOS has classes with multiple inheritance. CLOS objects are instances of classes.

CLOS does not make classes namespaces. CLOS also does not make methods reside inside classes and namespaces of those classes.

This means that CLOS is not message-passing OO. One does not pass a message to some object, where the object then runs the corresponding method.

Historically earlier object systems for Lisp, from which CLOS was developed, started as traditional class-based and message-passing systems (LOOPS, Flavors). With several years of experimentation and research the CLOS model was seen to fit better into Lisp and to be more powerful.

CLOS uses a generic function model, whose main advantage is that it fits better into a functional programming paradigm. CLOS uses function calling of generic functions. The generic function can have more than one argument and can dispatch on more than one argument. This fits into the rest of Common Lisp, since other functions also can have more than one argument. CLOS generic functions can also be passed around, returned from functions or be stored in data structures. So they are also first-class functions. If you find these things (higher-order functions and multiple dispatch) useful, then CLOS has an advantage. Additionally CLOS generic functions are CLOS objects themselves.

A few things then are different from other class-based OO-systems - the lack of a namespace per class and that methods are not organized by class is already mentioned above. Since CLOS is not message-passing OO, forwarding all messages sent to some object to another object does not apply - if there is no message-passing we cannot forward non-existant messages.

One obvious possible advantage is that since CLOS class do not bundle methods and methods can be defined individually, a class and the set of methods is not closed. One can add or remove new methods at any time. This means that for new or changed functionality, one does not need the source code, somehow 're-open' a class or even subclass a class to add the new functionality to a subclass. All that is not necessary in CLOS.

A few other possible advantages:

• CLOS has for organizing functionality the generic function. Thus functionality does not need to be scattered around classes, but can be brought together in generic functions.

• the dispatch mechanism of CLOS is extremely flexible. At runtime the effective method can be assembled from a set of applicable methods and the assembly can be controlled in almost arbitrary ways. This way new dispatching ways can be implemented by the user without the need to change the underlying implementation. An example is the implementation of Design by Contract. CLOS is so flexible that this can be implemented by a user.

Generally the advanced CLOS implementations are based on the idea that it is a default object system, but allows a wide variety of customizations of the object-system itself. Thus CLOS is defines a region of possible object-systems and not a single fixed one. The default functionality is already quite advanced: multiple inheritance, dynamic updates, multi-dispatch, method combinations, and more.

To read more about the design philosophy of CLOS, the Common Lisp Object System, see these papers:

• CLOS in Context: The Shape of the Design Space (Danny Bobrow, Jon L White, Richard P Gabriel), 1992
• CLOS: Integrating Object-Oriented and Functional Programming (Jon L White, Danny Bobrow, Richard P Gabriel), 1991

Asthenic

+1. On the practical front, multi-methods are a powerful way to reduce the sometimes unwelcome coupling and always unwelcome boilerplate that comes with double-dispatch and visitor patterns. Use of the meta-object protocol is a bit more esoteric, but I like the example of Design by Contract. – Alcaeus

I'd add that it has the advantage for common lisp programmers of being part of the standard. – Hiatt