1Programming language design combines the art of invention with judicious adaptationand rejection of ideas previously tried. This chapter presents aspects of the design of theCommon Lisp Object System (CLOS) in the context of related ideas from many languages,providing a view of the CLOS within a broader space of designs.CLOS is the latest in a long history of additions of object-oriented extensions to Lisp. ButCLOS is the first such extension that integrates the type and class systems, and providesa uniform client interface for calling ordinary functions and functions implemented in anobject-oriented style.CLOS is also designed with three constraints not found in other object-oriented exten-sions. The first is to provide essential compatibility with other previously used object-oriented LISP facilities, such as the Symbolics Flavors system. Essential compatibility im-plies an easy path for transforming programs, supporting the most frequently used capabili-ties in such systems. The second constraint is that CLOS is to facilitate experimentation withnew language features in a way that allows them to integrate but not interfere with the kernelof the system. The third is that CLOS kernel facilities are to be efficiently implementable ona wide range of hardware, from special purpose Lisp machine to RISC processors. The CLOSmetaobject protocol[18] supports these three constraints by making available to the user andsystem developer a specification for the interpreter for the language, and an object-orientedprotocol that supports extension. (Actually the metaobject protocol provides only a partialspecification—for only some steps—of the processing of CLOS. If certain customizations ofthose steps are made by the user, the effect is as if the interpreter were customized.)The four sections of this chapter provide four projections of the design space for object-oriented systems. In each, we characterize the range of variability found in current pro-gramming practice, locate CLOS in this context, and then explore extensions that might becoherently added to CLOS. The extensions are important for two reasons. First, a languagemust be judged not only on what it contains, but on what it leaves out. The extensionsare facilities that could have been included in CLOS, but only with the attendant risk ofcomplicating standard practice and reducing understandability. Secondly, these extensionsshow how the CLOS metaobject protocol provides a smooth continuum of capabilities fromsystem developer to user.The first section explores four traditions in which incremental definition of operations hasappeared. These include the object-oriented programming (OOP) languages, data-driveninterpreters, pattern-directed languages, and languages with polymorphism. Incrementaldefinition is important because it supports (i) conceptual separation of the interface and im-plementation(s) of an operation, (ii) extension and specialization of the domain of operationswith new implementations.The second section focuses on the concepts of class and type. It distinguishes five notionsof type and shows different ways the introduction of classes into a language can interactwith the type system. The CLOS choice of making classes support the entire type system isimportant in moving all of Common Lisp towards being object-oriented.The third section on factoring descriptions focuses on use of mixin classes, and on combin-ing and enhancing methods. Factoring descriptions in a programming language is important
[1]
William F. Clocksin,et al.
Programming in Prolog
,
1981,
Springer Berlin Heidelberg.
[2]
Daniel H. H. Ingalls.
A Simple Technique for Handling Multiple Polymorphism
,
1986,
OOPSLA.
[3]
Daniel G. Bobrow,et al.
Book review: The Art of the MetaObject Protocol By Gregor Kiczales, Jim des Rivieres, Daniel G. and Bobrow(MIT Press, 1991)
,
1991,
SGAR.
[4]
Elaine Kant,et al.
Programming expert systems in OPS5
,
1985
.
[5]
Daniel G. Bobrow,et al.
Common lisp object system specification
,
1988,
SIGP.
[6]
Randall B. Smith,et al.
SELF: The power of simplicity
,
1987,
OOPSLA '87.
[7]
Richard Paul Gabriel.
An organization for programs in fluid domains
,
1980
.
[8]
Craig Chambers,et al.
An efficient implementation of SELF, a dynamically-typed object-oriented language based on prototypes
,
1989,
OOPSLA '89.
[9]
Alan Snyder.
Encapsulation and inheritance in object-oriented programming languages
,
1986,
OOPSLA 1986.
[10]
Guy L. Steele,et al.
Common Lisp the Language
,
1984
.
[11]
Bent Bruun Kristensen,et al.
The BETA Programming Language
,
1987,
Research Directions in Object-Oriented Programming.
[12]
David A. Moon.
Object-oriented programming with flavors
,
1986,
OOPSLA 1986.
[13]
Peter Wegner.
Dimensions of object-based language design
,
1987,
OOPSLA 1987.
[14]
Andreas Paepcke,et al.
User-level language crafting: introducing the CLOS metaobject protocol
,
1993
.
[15]
WegnerPeter.
Dimensions of object-based language design
,
1987
.
[16]
David Robson,et al.
Smalltalk-80: The Language and Its Implementation
,
1983
.
[17]
Gregor Kiczales,et al.
Efficient method dispatch in PCL
,
1990,
LISP and Functional Programming.
[18]
Roland Ducournau,et al.
On Some Algorithms for Multiple Inheritance in Object-Oriented Programming
,
1987,
ECOOP.
[19]
Daniel G. Bobrow,et al.
Object-Oriented Programming: Themes and Variations
,
1989,
AI Mag..
[20]
Luca Cardelli,et al.
On understanding types, data abstraction, and polymorphism
,
1985,
CSUR.