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.
: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
.
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.
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.