Table of Contents
As of June 23, 2003, OpenMCL 0.14 supports a fairly large subset of the semi-standard MetaObject Protocol (MOP) for CLOS, as defined in chapters 5 and 6 of “The Art Of The Metaobject Protocol”, (Kiczales et al, MIT Press 1991, ISBN 0-262-61074-4); this specification is also available online at http://www.alu.org/mop/index.html.
The keyword :openmcl-partial-mop is on *FEATURES* to indicate the presence of this functionality.
All of the symbols defined in the MOP specification (whether implemented or not) are exported from the “CCL” package and from an “OPENMCL-MOP” package.
construct | status |
---|---|
accessor-method-slot-definition | + |
add-dependent | + |
add-direct-method | + |
add-direct-subclass | + |
add-method | + |
class-default-initargs | + |
class-direct-default-initargs | + |
class-direct-slots | + |
class-direct-subclasses | + |
class-direct-superclasses | + |
class-finalized-p | + |
class-prototype | + |
class-slots | + |
compute-applicable-methods | - |
compute-applicable-methods-using-classes | - |
compute-class-precedence-list | + |
compute-direct-initargs | + |
compute-discriminating-function | - |
compute-effective-method | + |
compute-effective-slot-definition | + |
compute-slots | + |
direct-slot-definition-class | + |
effective-slot-definition-class | + |
ensure-class | + |
ensure-class-using-class | + |
ensure-generic-function-using-class | + |
eql-specializer-object | + |
extract-lambda-list | + |
extract-specializer-names | + |
finalize-inheritance | + |
find-method-combination | + |
funcallable-standard-instance-access | + |
generic-function-argument-precedence-order | + |
generic-function-declarations | + |
generic-function-lambda-list | + |
generic-function-method-class | + |
generic-function-method-combination | + |
generic-function-methods | + |
generic-function-name | + |
intern-eql-specializer | + |
make-method-lambda | - |
map-dependents | + |
method-function | + |
method-generic-function | + |
method-lambda-list | + |
method-qualifiers | + |
method-specializers | + |
reader-method-class | + |
remove-dependent | + |
remove-direct-method | + |
remove-direct-subclass | + |
remove-method | + |
set-funcallable-instance-function | - |
slot-boundp-using-class | + |
slot-definition-allocation | + |
slot-definition-initargs | + |
slot-definition-initform | + |
slot-definition-initfunction | + |
slot-definition-location | + |
slot-definition-name | + |
slot-definition-readers | + |
slot-definition-type | + |
slot-definition-writers | + |
slot-makunbound-using-class | + |
slot-value-using-class | + |
specializer-direct-generic-functions | + |
specializer-direct-methods | + |
standard-instance-access | + |
update-dependent | + |
validate-superclass | + |
writer-method-class | + |
Note that those generic functions whose status is “-” in the table above deal with the internals of generic function dispatch and method invocation (the “Generic Function Invocation Protocol”.) Method functions are implemented a bit differently in OpenMCL from what the MOP expects, and it's not yet clear if or how this subprotocol can be well-supported.
Those constructs that are marked as “+” in the table above are nominally implemented as the MOP document specifies (deviations from the specification should be considered bugs; please report them as such.) Note that some CLOS implementations in widespread use (e.g., PCL) implement some things (ENSURE-CLASS-USING-CLASS comes to mind) a bit differently from what the MOP specifies.
The entire CLOS class and generic function hierarchy is effectively a (large, complicated) shared data structure; it's not generally practical for a thread to request exclusive access to all of CLOS, and the effects of volitional modification of the CLOS hierarchy (via clas redefinition, CHANGE-CLASS, etc) in a multithreaded environment aren't always tractable.
Native threads exacerbate this problem (in that they increase the opportunities for concurrent modification and access.) The implementation should try to ensure that a thread's view of any subset of the CLOS hierarchy is consistent (to the extent that that's possible) and should try to ensure that incidental modifications of the hierarchy (cache updates, etc.) happen atomically; it's not generally possible for the implementation to guarantee that a thread's view of things is correct and current.