The generic functions implementing slot access are like those described in AMOP, except that each takes a slot-name argument rather than a slot definition object, and the primary methods are therefore specialized differently.
For details, see slot-boundp-using-class, slot-value-using-class and slot-makunbound-using-class.
Note: by default, standard slot accessors, and access by slot-value to an argument of a method where the specializer is a class defined by defclass, are optimized to not call slot-value-using-class. This can be overridden with the :optimize-slot-access class option. See the second definition of virtual-metaclass below for an example of the use of this.
standard-instance-access is not supported as defined in AMOP. Note that there is an internal function of the same name, but this is not optimal. Also, funcallable-standard-instance-access is not supported. An alternative for fast instance access is to use the :optimize-slot-access class option.
standard-reader-method, standard-accessor-method and standard-writer-method all have a required :slot-name initarg, rather than a :slot-definition initarg as specified in AMOP.
Compatibility note: in LispWorks 4.3 and previous versions, accessor-method-slot-definition was not implemented. This is implemented in the current version.
LispWorks make-method-lambda is not AMOP-compatible. It takes separate lambda-list and body arguments, and the returned lambda form is different to that specified in AMOP (see 18.1.4 Method Functions below).
LispWorks does not support user defined methods for the generic function make-method-lambda.
LispWorks method functions take the same arguments as the method itself, whereas in AMOP they take a list of arguments and a list of next methods.
eql-specializer, eql-specializer-object and intern-eql-specializer are not implemented.
eql specializers in LispWorks are lists.
compute-applicable-methods-using-classes is not implemented.
compute-discriminating-function is implemented and returns the discriminator but:
compute-applicable-methods-using-classes since LispWorks does not have that function.Moreover add-method does not call compute-discriminating-function because this would be inefficient when doing multiple calls to add-method. Instead, compute-discriminating-function is called when the generic function is called.
method-combination objects do not contain the arguments, merely the type. There is a single method-combination object per type.
Therefore the value returned by generic-function-method-combination, and the default value of the :method-combination initarg, and the :method-combination argument processed by ensure-generic-function-using-class are specific only to the type of the method combination.
Also, find-method-combination is not implemented.
The AMOP defines that the standard primary method for validate-superclass should return true if the class of one of the arguments is standard-class and the class of the other is funcallable-standard-class.
In LispWorks, objects of these metaclasses are not completely compatible, so validate-superclass will return false in these cases.
Beware that defining a class that mixes standard-class and funcallable-standard-class can lead to inconsistencies with the predicate functionp, the type function and the class function.
funcallable-standard-object is implemented as defined in AMOP, except that its class precedence list has direct superclasses:
(function standard-object)
rather than:
(standard-object function)
so that LispWorks is compliant with the ANSI Common Lisp rules.
For details, see funcallable-standard-object.
LispWorks® User Guide and Reference Manual - 01 Dec 2021 19:30:21