Common Lisp Object System

From Wikipedia, the free encyclopedia

Jump to: navigation, search
For other uses, see Clos network.

The Common Lisp Object System (CLOS) is the facility for object-oriented programming which is part of ANSI Common Lisp. CLOS is a dynamic object system which differs radically from the OOP facilities found in more static languages such as C++ or Java. CLOS was inspired by earlier Lisp object systems such as MIT Flavors and CommonLOOPS, although it is more general than either. Originally proposed as an add-on, CLOS was adopted as part of the ANSI standard for Common Lisp and has been adapted into other Lisp dialects like EuLisp or Emacs Lisp.[1]

Contents

[edit] Features

The basic building blocks of CLOS are classes, instances of classes, generic functions and their methods. CLOS provides macros to define those: DEFCLASS, DEFGENERIC and DEFMETHOD. Instances are created with the function MAKE-INSTANCE.

Classes can have multiple superclasses, a list of slots (member variables in C++/Java parlance) and a special meta class. Slots can be allocated by class (static members) or by instance. Each slot has a name and the value of a slot can be accessed by that name. Additionally special generic functions can be defined to write or read values of slots. Each slot in a CLOS class must have a unique name.

CLOS is a multiple dispatch system. This means that methods can be specialized upon any or all of their arguments. Most OO languages are single-dispatch, meaning that methods are only specialized on the first argument. Another unusual feature is that methods do not "belong" to classes; classes do not provide a namespace for generic functions or methods. Methods are defined separately from classes, and they have no special access (e.g. this, self, or protected) to class slots.

Methods in CLOS are grouped into generic functions. A generic function is a collection of methods with a shared name and argument structure, each specialized for different arguments. Since Common Lisp provides non-CLOS classes for structures and built-in data types (numbers, strings, characters, symbols, ...), CLOS dispatch works also with these non-CLOS classes. CLOS also supports dispatch over individual objects (eql specializers). CLOS does not support dispatch over all Common Lisp data types (for example dispatch does not work for fully-specialized array types or for types introduced by DEFTYPE).

Dispatch in CLOS is also different from most OO languages: 1) given a list of arguments, a list of applicable methods is determined. 2) This list is sorted according to the specificity of their parameter specializers. 3) Selected methods from this list then are combined into an effective method using the method combination used by the generic function. The effective method is then called with the original arguments. This dispatch mechanism works at runtime. Adding or removing methods thus may lead to changed effective methods (even when the generic function is called with the same arguments) at runtime. Changing the method combination also may lead to different effective methods.

For example,

(defgeneric f (x y)) ; declare the common argument structure prototype
(defmethod f ((x integer) y) 1) ; define an implementation for (f integer t), where t matches all types
(f 1 2.0) => 1
(defmethod f ((x integer) (y real)) 2) ; define an implementation for (f integer real), where real ~ float
(f 1 2.0) => 2 ; dispatch changed at runtime

Like the OO systems in most dynamic languages, CLOS does not enforce encapsulation. Any data member (or slot) can be accessed using the slot-value function or via (optionally auto-generated) accessor methods. But you have to know the name for the slot to access it via slot-value. CL programmers use the language's package facility to declare which functions or data structures are intended for export.

Apart from normal ("primary") methods, there also are :before, :after, and :around methods. These modify the order in which methods are executed on a derived class. An :around method can specify whether the primary method is executed at all. Additionally, the programmer can adjust if all possible primary methods along the class hierarchy should be called or just the one providing the closest match.

The Standard Method-Combination provides above primary, before, after and around methods. There are other Method-Combinations with other method types. New (both simple and complex) Method-Combinations and method types can be defined.

CLOS allows multiple inheritance. When the default order in which methods are executed in multiple inheritance is not correct, the programmer may resolve the diamond inheritance problems by specifying the order of method combinations.

CLOS is dynamic, meaning that not only the contents, but also the structure of its objects can be modified at runtime. CLOS supports changing class definitions on-the-fly (even when instances of the class in question already exist) as well as changing the class membership of a given instance through the change-class operator. CLOS also allows one to add, redefine and remove methods at runtime.

CLOS is not a prototype language: Classes must be defined before objects can be instantiated as a member of that class.

[edit] Meta-Object Protocol

Outside of the ANSI standard, there is a widely implemented extension to CLOS called the Meta-Object Protocol (MOP). The MOP defines a standard interface to the underpinnings of the CLOS implementation, treating classes, slot-descriptions, generic-functions and methods themselves as instances of metaclasses, and allows the definition of new metaclasses and the modification of all CLOS behavior. The flexibility of the CLOS MOP prefigures aspect-oriented programming, which was later developed by some of the same engineers, such as Gregor Kiczales. The MOP defines the behavior of the whole object system by a set of protocols. These are defined in terms of CLOS. Thus it is possible to create new object-systems by extending or changing the provided CLOS functionality. The Book The Art of the Metaobject Protocol describes the use and implementation of the CLOS MOP.

[edit] Influences from older Lisp-based Object Systems

Flavors (and its succesor New Flavors) was the object system on the MIT Lisp Machine. Large parts of the Lisp Machine operating systems and many applications for it are using Flavors or New Flavors. Flavors is mostly obsolete, though implementations for Common Lisp do exist. Flavors was using the message passing paradigm. New Flavors introduced generic functions.

CommonLoops was the successor of LOOPS (from Xerox InterLisp-D). CommonLoops was implemented for Common Lisp. A portable implementation called Portable CommonLoops (PCL) was the first implementation of CLOS. PCL is widely ported and still provides the base for the CLOS implementation of several Common Lisp implementations. PCL is implemented mostly in portable Common Lisp with only a few system dependent parts.

[edit] References

  1. ^ "CLOS is a standard. Multiple vendors supply CLOS. CLOS (or parts of it) is being used to add object orientation to other Lisp dialects such as EuLisp or Emacs Lisp." pg 110 of Veitch 1998
  • "CommonLoops: merging Lisp and object-oriented programming", by Daniel G. Bobrow, Kenneth Kahn, Gregor Kiczales, Larry Masinter, Mark Stefik, Frank Zdybel. 1986, Portland, Oregon, United States. Pages 17 - 29 of the Conference on Object Oriented Programming Systems Languages and Applications, ISSN 0362-1340.
  • "A History and Description of CLOS", by Jim Veitch. Pages 107-158 of Handbook of Programming Languages, Volume IV: Functional and Logic Programming Languages, ed. Peter H. Salus. 1998 (1st edition), Macmillian Technical Publishing; ISBN 1-57870-011-6

[edit] Literature

Retrieved from "http://en.wikipedia.org/wiki/Common_Lisp_Object_System"
Personal tools