# Writing Portable Extensions to the Object System using the MetaObject Protocol

## Overview

&CCL; 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.

## Implementation status

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 &CCL; 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.

## Concurrency issues

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

If you are loading code and defining classes in the most usual way, which is to say, via the compiler, using only a single thread, these issues are probably not going to affect you much.

If, however, you are making finicky changes to the class hierarchy while you're running multiple threads which manipulate objects related to each other, more care is required. Before doing such a thing, you should know what you're doing and already be aware of what precautions to take, without being told. That said, if you do it, you should seriously consider what your application's critical data is, and use locks for critical code sections.