The Common Lisp Object System (CLOS) is the facility for object-oriented programming in ANSI Common Lisp. CLOS is a powerful 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 such as EuLisp or Emacs Lisp. [1]
The basic building blocks of CLOS are methods, classes, instances of those classes, and generic functions. CLOS provides macros to define those: defclass
, defmethod
, and defgeneric
. Instances are created with the method make-instance
.
Classes can have multiple superclasses, a list of slots (member variables in C++/Java parlance) and a special metaclass. Slots can be allocated by class (all instances of a class share the slot) or by instance. Each slot has a name and the value of a slot can be accessed by that name using the function slot-value
. 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 required 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 an object which is callable like a function and which associates 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 by default 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
). However, most Common Lisp implementations provide a metaobject protocol which allows generic functions to provide application specific specialization and dispatch rules.
Dispatch in CLOS is also different from most OO languages:
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,
; Declare the common argument structure prototype.(defgenericf(xy)); Define an implementation for (f integer y), where y matches all types.(defmethodf((xinteger)y)1)(f12.0)=>1; Define an implementation for (f integer real).(defmethodf((xinteger)(yreal))2)(f12.0)=>2;Dispatch changed at runtime.
Like the OO systems in most dynamic languages, CLOS does not enforce encapsulation. Any slot can be accessed using the slot-value
function or via (optionally auto-generated) accessor methods. To access it via slot-value
you have to know the name of the slot. 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
"auxiliary" methods. The former two are invoked prior to, or after the primary method, in a particular order based on the class hierarchy. An :around
method can control whether the primary method is executed at all. Additionally, the programmer can specify whether all possible primary methods along the class hierarchy should be called or just the one providing the closest match.
The Standard Method-Combination provides the primary, before, after and around methods explained above. 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. The Circle-Ellipse Problem is readily solved in CLOS, and most OOP design patterns either disappear or are qualitatively simpler. [2]
CLOS is not a prototype language: classes must be defined before objects can be instantiated as members of that class.
Outside of the ANSI Common Lisp standard, there is a widely implemented extension to CLOS called the Metaobject 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.
The various Common Lisp implementations have slightly different support for the Meta-Object Protocol. The Closer [3] project aims to provide the missing features.
Flavors (and its successor New Flavors) was the object system on the MIT Lisp Machine. Large parts of the Lisp Machine operating systems and many applications for it use Flavors or New Flavors. Flavors introduced multiple inheritance and mixins, among other features. 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.
Because of the power and expressivity of CLOS, as well as the historical availability of Tiny CLOS (a simplified portable CLOS implementation written by Gregor Kiczales for use with Scheme), CLOS-like MOP-based object systems have become the de facto norm in most Lisp dialect implementations, as well as finding their way into some other languages' OOP facilities:
Common Lisp (CL) is a dialect of the Lisp programming language, published in American National Standards Institute (ANSI) standard document ANSI INCITS 226-1994 (S2018). The Common Lisp HyperSpec, a hyperlinked HTML version, has been derived from the ANSI Common Lisp standard.
In object-oriented programming, a class is an extensible program-code-template for creating objects, providing initial values for state and implementations of behavior.
Dylan is a multi-paradigm programming language that includes support for functional and object-oriented programming (OOP), and is dynamic and reflective while providing a programming model designed to support generating efficient machine code, including fine-grained control over dynamic and static behaviors. It was created in the early 1990s by a group led by Apple Computer.
Lisp is a family of programming languages with a long history and a distinctive, fully parenthesized prefix notation. Originally specified in the late 1950s, it is the second-oldest high-level programming language still in common use, after Fortran. Lisp has changed since its early days, and many dialects have existed over its history. Today, the best-known general-purpose Lisp dialects are Common Lisp, Scheme, Racket, and Clojure.
Multiple inheritance is a feature of some object-oriented computer programming languages in which an object or class can inherit features from more than one parent object or parent class. It is distinct from single inheritance, where an object or class may only inherit from one particular object or class.
A visitor pattern is a software design pattern that separates the algorithm from the object structure. Because of this separation, new operations can be added to existing object structures without modifying the structures. It is one way to follow the open/closed principle in object-oriented programming and software engineering.
Prototype-based programming is a style of object-oriented programming in which behaviour reuse is performed via a process of reusing existing objects that serve as prototypes. This model can also be known as prototypal, prototype-oriented,classless, or instance-based programming.
Multiple dispatch or multimethods is a feature of some programming languages in which a function or method can be dynamically dispatched based on the run-time (dynamic) type or, in the more general case, some other attribute of more than one of its arguments. This is a generalization of single-dispatch polymorphism where a function or method call is dynamically dispatched based on the derived type of the object on which the method has been called. Multiple dispatch routes the dynamic dispatch to the implementing function or method using the combined characteristics of one or more arguments.
In computer programming, a generic function is a function defined for polymorphism.
Programming languages can be grouped by the number and types of paradigms supported.
A method in object-oriented programming (OOP) is a procedure associated with an object, and generally also a message. An object consists of state data and behavior; these compose an interface, which specifies how the object may be used. A method is a behavior of an object parametrized by a user.
In computer science, a dynamic programming language is a class of high-level programming languages which at runtime execute many common programming behaviours that static programming languages perform during compilation. These behaviors could include an extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system. Although similar behaviors can be emulated in nearly any language, with varying degrees of difficulty, complexity and performance costs, dynamic languages provide direct tools to make use of them. Many of these features were first implemented as native features in the Lisp programming language.
In object-oriented programming languages, a mixin is a class that contains methods for use by other classes without having to be the parent class of those other classes. How those other classes gain access to the mixin's methods depends on the language. Mixins are sometimes described as being "included" rather than "inherited".
In computer science, reflective programming or reflection is the ability of a process to examine, introspect, and modify its own structure and behavior.
In computer science, a metaobject is an object that manipulates, creates, describes, or implements objects. The object that the metaobject pertains to is called the base object. Some information that a metaobject might define includes the base object's type, interface, class, methods, attributes, parse tree, etc. Metaobjects are examples of the computer science concept of reflection, where a system has access to its own internal structure. Reflection enables a system to essentially rewrite itself on the fly, to alter its own implementation as it executes.
Flavors, an early object-oriented extension to Lisp developed by Howard Cannon at the MIT Artificial Intelligence Laboratory for the Lisp machine and its programming language Lisp Machine Lisp, was the first programming language to include mixins. Symbolics used it for its Lisp machines, and eventually developed it into New Flavors; both the original and new Flavors were message passing OO models. It was hugely influential in the development of the Common Lisp Object System (CLOS).
EuLisp is a statically and dynamically scoped Lisp dialect developed by a loose formation of industrial and academic Lisp users and developers from around Europe. The standardizers intended to create a new Lisp "less encumbered by the past", and not so minimalist as Scheme. Another objective was to integrate the object-oriented programming paradigm well. It is a third-generation programming language.
CommonLoops is an early programming language which extended Common Lisp to include Object-oriented programming functionality and is a dynamic object system which differs from the OOP facilities found in static languages such as C++ or Java. Like New Flavors, CommonLoops supported multiple inheritance, generic functions and method combination. CommonLoops also supported multi-methods and made use of metaobjects. CommonLoops and New Flavors were the primary ancestors of CLOS. CommonLoops was supported by a portable implementation known as Portable CommonLoops (PCL) which ran on all Common Lisp implementations of the day.
The circle–ellipse problem in software development illustrates several pitfalls which can arise when using subtype polymorphism in object modelling. The issues are most commonly encountered when using object-oriented programming (OOP). By definition, this problem is a violation of the Liskov substitution principle, one of the SOLID principles.
The Art of the Metaobject Protocol (AMOP) is a 1991 book by Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow on the subject of metaobject protocol.