6.2 Metaobject Protocol

SBCL supports a metaobject protocol which is intended to be compatible with AMOP; present exceptions to this (as distinct from current bugs) are:

• compute-effective-method only returns one value, not two.

  There is no record of what the second return value was meant to indicate, and apparently no clients for it.

• the arguments :declare and :declarations to ensure-generic-function are both accepted, with the leftmost argument defining the declarations to be stored and returned by generic-function-declarations.

  Where AMOP specifies :declarations as the keyword argument to ensure-generic-function, the Common Lisp standard specifies :declare. Portable code should use :declare.

• although SBCL obeys the requirement in AMOP for validate-superclass for standard-class and funcallable-standard-class to be compatible metaclasses, we impose an additional requirement at class finalization time: a class of metaclass funcallable-standard-class must have function in its superclasses, and a class of metaclass standard-class must not.

  At class finalization, a class prototype which is accessible by a standard mop function sb-mop:class-prototype. The user can then ask whether this object is a function or not in several different ways: whether it is a function according to typep; whether its class-of is subtypep function, or whether function appears in the superclasses of the class. The additional consistency requirement comes from the desire to make all of these answers the same.

  The following class definitions are bad, and will lead to errors either immediately or if an instance is created:

            (defclass bad-object (funcallable-standard-object)
              ()
              (:metaclass standard-class))
       

            (defclass bad-funcallable-object (standard-object)
              ()
              (:metaclass funcallable-standard-class))
       

  The following definition is acceptable:

            (defclass mixin ()
              ((slot :initarg slot)))
            (defclass funcallable-object (funcallable-standard-object mixin)
              ()
              (:metaclass funcallable-standard-class))
       

  and leads to a class whose instances are funcallable and have one slot.

• the requirement that “No portable class C_p 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.” is interpreted to mean that the standardized classes themselves should not have slots named by external symbols of public packages.

  The rationale behind the restriction is likely to be similar to the ANSI Common Lisp restriction on defining functions, variables and types named by symbols in the Common Lisp package: preventing two independent pieces of software from colliding with each other.

• specializations of the new-value argument to (setf sb-mop:slot-value-using-class) are not allowed: all user-defined methods must have a specializer of the class t.

  This prohibition is motivated by a separation of layers: the slot-value-using-class family of functions is intended for use in implementing different and new slot allocation strategies, rather than in performing application-level dispatching. Additionally, with this requirement, there is a one-to-one mapping between metaclass, class and slot-definition-class tuples and effective methods of (setf slot-value-using-class), which permits optimization of (setf slot-value-using-class)'s discriminating function in the same manner as for slot-value-using-class and slot-boundp-using-class.

  Note that application code may specialize on the new-value argument of slot accessors.