5.3 Inheritance Structure Of Metaobject Classes

The inheritance structure of the specified metaobject classes is shown in the table below (FIXME: insert anchor).

Direct superclass relationships among the specified metaobject classes. The class of every class shown is standard-class except for the class t which is an instance of the class built-in-class and the classes generic-function and standard-generic-function which are instances of the class funcallable-standard-class.

Metaobject Class

Direct Superclasses

standard-object

(t)

funcallable-standard-object

(standard-object function)

metaobject

(standard-object)

generic-function

(metaobject funcallable-standard-object)

standard-generic-function

(generic-function)

method

(metaobject)

standard-method

(method)

standard-accessor-method

(standard-method)

standard-reader-method

(standard-accessor-method)

standard-writer-method

(standard-accessor-method)

method-combination

(metaobject)

slot-definition

(metaobject)

direct-slot-definition

(slot-definition)

effective-slot-definition

(slot-definition)

standard-slot-definition

(slot-definition)

standard-direct-slot-definition

(standard-slot-definition direct-slot-definition)

standard-effective-slot-definition

(standard-slot-definition effective-slot-definition)

specializer

(metaobject)

eql-specializer

(specializer)

class

(specializer)

built-in-class

(class)

forward-referenced-class

(class)

standard-class

(class)

funcallable-standard-class

(class)

Each class marked with a ``*'' is an abstract class and is not intended to be instantiated. The results are undefined if an attempt is made to make an instance of one of these classes with make-instance.

The classes standard-class, standard-direct-slot-definition, standard-effective-slot-definition, standard-method, standard-reader-method, standard-writer-method, and standard-generic-function are called standard metaobject classes. For each kind of metaobject, this is the class the user interface macros presented in the CLOS Specification use by default. These are also the classes on which user specializations are normally based.

The classes built-in-class, funcallable-standard-class and forward-referenced-class are special-purpose class metaobject classes. Built-in classes are instances of the class built-in-class. The class funcallable-standard-class provides a special kind of instances described in the section called ``Funcallable Instances.'' When the definition of a class references another class which has not yet been defined, an instance of forward-referenced-class is used as a stand-in until the class is actually defined.

The class standard-object is the default direct superclass of the class standard-class. When an instance of the class standard-class is created, and no direct superclasses are explicitly specified, it defaults to the class standard-object. In this way, any behavior associated with the class standard-object will be inherited, directly or indirectly, by all instances of the class standard-class. A subclass of standard-class may have a different class as its default direct superclass, but that class must be a subclass of the class standard-object.

The same is true for funcallable-standard-class and funcallable-standard-object.

The class specializer captures only the most basic behavior of method specializers, and is not itself intended to be instantiated. The class class is a direct subclass of specializer reflecting the property that classes by themselves can be used as method specializers. The class eql-specializer is used for eql specializers.

• Implementation and user specialization.
  • Restrictions on implementations
  • Restrictions on portable programs

Note:

Taken literally, this page suggests that the metaclass of funcallable-standard-object is standard-class, but we think that is a mistake, and that the metaclass should be funcallable-standard-class instead.

5.3.1 Implementation And User Specialization

5.3.2 Restrictions On Implementations

Implementations are allowed latitude to modify the structure of specified classes and methods. This includes: the interposition of implementation-specific classes; the promotion of specified methods; and the consolidation of two or more specified methods into a single method specialized to interposed classes.

Any such modifications are permitted only so long as for any portable class Cp that is a subclass of one or more specified classes C0 ... Ci, the following conditions are met:

• In the actual class precedence list of Cp, the classes C0 ... Ci must appear in the same order as they would have if no implementation-specific modifications had been made.

• The method applicability of any specified generic function must be the same in terms of behavior as it would have been had no implementation-specific changes been made. This includes specified generic functions that have had portable methods added. In this context, the expression ``the same in terms of behavior'' means that methods with the same behavior as those specified are applicable, and in the same order.

• No portable class Cp may inherit, by virtue of being a direct or indirect subclass of a specified class, any slot for which the name is a symbol accessible in the common-lisp-user package or exported by any package defined in the ANSI Common Lisp standard.

• Implementations are free to define implementation-specific before- and after-methods on specified generic functions. Implementations are also free to define implementation-specific around-methods with extending behavior.

5.3.3 Restrictions On Portable Programs

Portable programs are allowed to define subclasses of specified classes, and are permitted to define methods on specified generic functions, with the following restrictions. The results are undefined if any of these restrictions is violated.

• Portable programs must not redefine any specified classes, generic functions, methods or method combinations. Any method defined by a portable program on a specified generic function must have at least one specializer that is neither a specified class nor an eql specializer whose associated value is an instance of a specified class.

• Portable programs may define methods that extend specified methods unless the description of the specified method explicitly prohibits this. Unless there is a specific statement to the contrary, these extending methods must return whatever value was returned by the call to call-next-method.

• Portable programs may define methods that override specified methods only when the description of the specified method explicitly allows this. Typically, when a method is allowed to be overridden, a small number of related methods will need to be overridden as well.

  An example of this is the specified methods on the generic functions add-dependent, remove-dependent, and map-dependents. Overriding a specified method on one of these generic functions requires that the corresponding method on the other two generic functions be overridden as well.

• Portable methods on specified generic functions specialized to portable metaobject classes must be defined before any instances of those classes (or any subclasses) are created, either directly or indirectly by a call to make-instance. Methods can be defined after instances are created by allocate-instance however. Portable metaobject classes cannot be redefined.

  Implementation note:

  The purpose of this last restriction is to permit implementations to provide performance optimizations by analyzing, at the time the first instance of a metaobject class is initialized, what portable methods will be applicable to it. This can make it possible to optimize calls to those specified generic functions which would have no applicable portable methods.

  Note:

  The specification technology used in this document needs further development. The concepts of object-oriented protocols and subclass specialization are intuitively familiar to programmers of object-oriented systems; the protocols presented here fit quite naturally into this framework. Nonetheless, in preparing this document, we have found it difficult to give specification-quality descriptions of the protocols in a way that makes it clear what extensions users can and cannot write. Object-oriented protocol specification is inherently about specifying leeway, and this seems difficult using current technology.