Package closer-mop

General Information
License
The Closer Project
Closer to MOP
Generic Functions and Methods
Initialization of Class Metaobjects
Initialization of Generic Function Metaobjects
Initialization of Method Metaobjects
Initialization of Slot Definition Metaobjects
Readers for Class Metaobjects
Readers for Generic Function Metaobjects
Readers for Method Metaobjects
Readers for Slot Definition Metaobjects

General Information

Author

Pascal Costanza

Version

The documented library has the version 0.61.

Homepage

http://common-lisp.net/project/closer/closer-mop.html

Mailing List

closer-announce for announcements

and

closer-devel for discussions, suggestions, questions, etc.

Download

The software is available as a set of darcs repositories. (Darcs is a revision control system similar to cvs or Subversion.) If you don't have darcs installed, you can also simply download the software from the http server by using tools like wget, or so. You can also get tarballs of the most recent 'official' releases. Finally, closer-mop is also asdf-installable.

Download a tarball from http://common-lisp.net/project/closer/ftp/

Source Code

Darc repository is available from http://common-lisp.net/project/closer/repos/closer-mop

Dependencies

closer-mop does not depend on other libraries.

License

Copyright (c) 2005 - 2010 Pascal Costanza

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The Closer Project

The library closer-mop is part of the Closer Project. This project is an umbrella project for a few subprojects whose aim is to improve the usability of the CLOS MOP across different Common Lisp implementations. The first step is a library that checks what features of the AMOP specification is supported by a given CL implementation. This results in a number of keywords that describe the various aspects of a MOP.

The second step is Closer to MOP, a compatibility library that provides a package that adds missing features and/or replaces existing features with versions that better reflect the AMOP specs. If the latter is not possible, it provides utility functions that allow one to work around restrictions.

Finally, the Closer project should host a few example metaclasses, including some of the examples given in AMOP, and probably others as well. It is important to provide example applications of the MOP because they implicitly provide test cases against which new MOP implementations can be checked for compatibility. So in the long run, the Closer project should help to bring the MOP into a shape that Common Lisp programmers can better rely on across many implementations.

As of August 2005, ContextL has been added as a first non-trivial example. It is a full-fledged CLOS extension in its own right, providing language constructs for Context-oriented Programming (COP). See also my homepage for further information on COP.

As of February 2006, AspectL has been added to the Closer Project.

As of December 2009, Closer to MOP has received a major improvement in that the generic function invocation protocols are now supported consistently across a broad range of Common Lisp implementations.

As of December 2009, Filtered Functions have been added to the Closer Project.

Closer to MOP

Closer to MOP is a compatibility layer that rectifies many of the absent or incorrect MOP features across a broad range of Common Lisp implementations.

New in version 0.61:

• Added support for LispWorks 6.0.

Highlights of version 0.6:

• Completely reworked support for Embeddable Common Lisp.
• Resurrected support for Macintosh Common Lisp (now RMCL).
• Added partial support for Scieneer Common Lisp.
• Closer to MOP now recognizes and supports 9 different Common Lisp implementations.
• Added improved and complete generic function invocation protocols to Clozure Common Lisp, CLisp, ECL, LispWorks and SBCL. This includes support for COMPUTE-EFFECTIVE-METHOD-FUNCTION (a piece missing in AMOP) and MAKE-METHOD-LAMBDA in all these implementations (except for ECL, where I currently cannot support MAKE-METHOD-LAMBDA). Note: in order to ensure that MAKE-METHOD-LAMBDA doesn't create surprising results (or better: surprisingly doesn't create the results you expect), it is now ensured that DEFGENERIC creates a generic function metaobject in the compilation environment (without the method definitions), and it is now checked in DEFMETHOD that such a generic function metaobject exists for the method to be defined. If such a generic function metaobject doesn't exist, a STYLE-WARNING is issued (except for SBCL, which itself already issues a STYLE-WARNING in this case).
• The standard metobject definition macros and functions (DEFCLASS, DEFGENERIC, DEFMETHOD, ENSURE-CLASS, ENSURE-GENERIC-FUNCTION, etc.) sometimes forced the use of the replacement 'standard' metaobject classes of Closer to MOP (STANDARD-CLASS, STANDARD-GENERIC-FUNCTION and STANDARD-METHOD). This is now completely removed: If you don't use a :METACLASS or :GENERIC-FUNCTION-CLASS option explicitly, these defining operators will use the internal metaclasses of the respective Common Lisp implementation, under the assumption that they are usually more efficient than the replacements in Closer to MOP. If for some reason, you want to ensure to use the replacements, you have to do so explicitly. (Note: The main purpose of the replacements is to provide a common compatible basis for your own metaobject subclasses, not to be used in their own right.)
• Replaced synchronization statements in Allegro and LispWorks with versions that will be compatible with their future SMP support.
• In LispWorks, automatically generated slot readers and writers now only call SLOT-VALUE-USING-CLASS and (SETF SLOT-VALUE-USING-CLASS) if there are actually definitions available for them. Otherwise, they use the native optimized slot access.
• Simplified and improved conditionalizations for Clozure Common Lisp and LispWorks, and removed mentions of OpenMCL (which was just the old name for Clozure Common Lisp).
• Reorganized the code: Moved all package definitions into one place, moved shared code into one common file, and removed the subfolders per CL implementations. (This is mostly to make the maintainer's job easier.)
• Added an Allegro-specific system definition.
• Lots of small little bug fixes and improvements here and there.
• Extra special thanks to Duane Rettig, Steve Haflich, and Juan Jose Garcia-Ripoll for fixing extra hard bugs in extra short amount of time.

Highlights of version 0.55:

• Added standard-instance-access and funcallable-standard-instance-access to LispWorks, due to popular request.
• Added a utility function subclassp that is sometimes more robust than subtypep (but subtypep should be preferred whenever possible).

Highlights of version 0.5:

• Ensured that a defgeneric form makes a generic function metaobject available in the compile-time environment. Otherwise, defmethod may not yield a method of the correct method metaobject class.
• Removed dependency on lw-compat.
• Added support for compute-discriminating-function in Clozure Common Lisp and OpenMCL, based on code provided by Slava Akhmechet.
• Added a classp predicate, due to Willem Broekema.

Highlights of version 0.4:

• Utility function REQUIRED-ARGS added for collecting the required arguments of a lambda list.
• Utility function ENSURE-FINALIZED added for ensuring that a class metaobject is finalized.

Closer to MOP has an asdf system definition, so it should be straightforward to include it in your own projects. The package that exports the relevant symbols is called CLOSER-MOP or short C2MOP.

Note that in some cases, symbols from the underlying MOP implementation or even the underlying COMMON-LISP package are shadowed in Closer to MOP. So if you use the CLOSER-MOP package you may need to shadow-import those symbols. Alternatively, you can use the packages CLOSER-COMMON-LISP and CLOSER-COMMON-LISP-USER that provide the symbols of COMMON-LISP / COMMON-LISP-USER plus the symbols of the CLOS MOP and the necessary shadow-imported symbols.

For details on what has or has not been fixed, see the accompanying file features.txt. Please also check the comments that come with the source code.

Currently, the following Common Lisp implementations are supported:

• Allegro Common Lisp 8.2 Express Edition.
• CLisp 2.49
• Clozure Common Lisp 1.8
• CMU Common Lisp 20c
• Embeddable Common Lisp 12.2.1
• LispWorks 6.0.1, Personal Edition
• LispWorks 6.1, Professional Edition
• Steel Bank Common Lisp 1.0.58
• Scieneer Common Lisp 1.3.9

All tests have been performed on Mac OS X 10.7.3, except for Scieneer Common Lisp which has been tested on CentOS 4.8.

The following implementations were supported in the past:

• Allegro Common Lisp 7.0, 8.0 - 8.2 Enterprise Editions.
• CLisp from 2.35 onward
• Clozure Common Lisp 1.2 - 1.7
• CMU Common Lisp 19c-f, 20a, 20b
• Embeddable Common Lisp 9.12.3, 10.3.1, 10.4.1, 11.1.1
• LispWorks 4.3 & 4.4, Personal and Professional Editions
• LispWorks 5.0.1, 5.0.2, 5.1.0 - 5.1.2 Personal and Professional Editions
• LispWorks 6.0, 6.0.1 Enterprise Editions
• Macintosh Common Lisp 5.1, 5.2.1
• OpenMCL 1.0
• Steel Bank Common Lisp from 0.9.16 onward (except version 1.0.0)

The respective code conditionalizations are still in the source files, so there is a good chance that they still work, especially for current or newer versions. However, there is no garantuee that this is the case, and active work for these implementations is currently on hold.

Generic Functions and Methods

This chapter describes each of the functions and generic functions that make up the CLOS Metaobject Protocol. The descriptions appear in alphabetical order with the exception that all the reader generic functions for each kind of metaobject are grouped together. So, for example, method-function would be found with method-qualifiers and other method metaobject readers under "Readers for Method Metaobjects".

The description of functions follows the same form as used in the CLOS specification. The description of generic functions is similar to that in the CLOS specification, but some minor changes have been made in the way methods are presented.

The description of a generic function includes a description of its behavior. This provides the general behavior, or protocol of the generic function. All methods defined on the generic function, both portable and specified, must have behavior consistent with this description.

Every generic function described in this section is an instance of the class standard-generic-function and uses standard method combination.

The description of a generic function also includes descriptions of the specified methods for that generic function. In the description of these methods, a method signature is used to describe the parameters and parameter specializers of each method.

The description of each method includes a description of the behavior particular to that method.

Initialization of Class Metaobjects

A class metaobject can be created by calling make-instance. The initialization arguments establish the definition of the class. A class metaobject can be redefined by calling reinitialize-instance. Some classes of class metaobject do not support redefinition; in these cases, reinitialize-instance signals an error.

Initialization of a class metaobject must be done by calling make-instance and allowing it to call initialize-instance. Reinitialization of a class metaobject must be done by calling reinitialize-instance. Portable programs must not call initialize-instance directly to initialize a class metaobject. Portable programs must not call shared-initialize directly to initialize or reinitialize a class metaobject. Portable programs must not call change-class to change the class of any class metaobject or to turn a non-class object into a class metaobject.

Since metaobject classes may not be redefined, no behavior is specified for the result of calls to update-instance-for-redefined-class on class metaobjects. Since the class of class metaobjects may not be changed, no behavior is specified for the result of calls to update-instance-for-different-class on class metaobjects.

During initialization or reinitialization, each initialization argument is checked for errors and then associated with the class metaobject. The value can then be accessed by calling the appropriate accessor as shown in Table class-mo-initargs.

This section begins with a description of the error checking and processing of each initialization argument. This is followed by a table showing the generic functions that can be used to access the stored initialization arguments. Initialization behavior specific to the different specified class metaobject classes comes next. The section ends with a set of restrictions on portable methods affecting class metaobject initialization and reinitialization.

In these descriptions, the phrase "this argument defaults to value" means that when that initialization argument is not supplied, initialization or reinitialization is performed as if value had been supplied. For some initialization arguments this could be done by the use of default initialization arguments, but whether it is done this way is not specified. Implementations are free to define default initialization arguments for specified class metaobject classes. Portable programs are free to define default initialization arguments for portable subclasses of the class class.

Unless there is a specific note to the contrary, then during reinitialization, if an initialization argument is not supplied, the previously stored value is left unchanged.

• The :direct-default-initargs argument is a list of canonicalized default initialization arguments.
  
  An error is signaled if this value is not a proper list, or if any element of the list is not a canonicalized default initialization argument.
  
  If the class metaobject is being initialized, this argument defaults to the empty list.



• The :direct-slots argument is a list of canonicalized slot specifications.
  
  An error is signaled if this value is not a proper list or if any element of the list is not a canonicalized slot specification.
  
  After error checking, this value is converted to a list of direct slot definition metaobjects before it is associated with the class metaobject. Conversion of each canonicalized slot specification to a direct slot definition metaobject is a two-step process. First, the generic function direct-slot-definition-class is called with the class metaobject and the canonicalized slot specification to determine the class of the new direct slot definition metaobject; this permits both the class metaobject and the canonicalized slot specification to control the resulting direct slot definition metaobject class. Second, make-instance is applied to the direct slot definition metaobject class and the canonicalized slot specification. This conversion could be implemented as shown in the following code:

  (defun convert-to-direct-slot-definition (class canonicalized-slot)
    (apply #'make-instance
           (apply #'direct-slot-definition-class
                  class canonicalized-slot)
           canonicalized-slot))        

  If the class metaobject is being initialized, this argument defaults to the empty list.
  
  Once the direct slot definition metaobjects have been created, the specified reader and writer methods are created. The generic functions reader-method-class and writer-method-class are called to determine the classes of the method metaobjects created.



• The :direct-superclasses argument is a list of class metaobjects. Classes which do not support multiple inheritance signal an error if the list contains more than one element.
  
  An error is signaled if this value is not a proper list or if validate-superclass applied to class and any element of this list returns false.
  
  When the class metaobject is being initialized, and this argument is either not supplied or is the empty list, this argument defaults as follows: if the class is an instance of standard-class or one of its subclasses the default value is a list of the class standard-object; if the class is an instance of funcallable-standard-class or one of its subclasses the default value is list of the class funcallable-standard-object.
  
  After any defaulting of the value, the generic function add-direct-subclass is called once for each element of the list.
  
  When the class metaobject is being reinitialized and this argument is supplied, the generic function remove-direct-subclass is called once for each class metaobject in the previously stored value but not in the new value; the generic function add-direct-subclass is called once for each class metaobject in the new value but not in the previously stored value.



• The :documentation argument is a string or nil.
  
  An error is signaled if this value is not a string or nil.
  
  If the class metaobject is being initialized, this argument defaults to nil.



• The :name argument is an object.
  
  If the class is being initialized, this argument defaults to nil.

After the processing and defaulting of initialization arguments described above, the value of each initialization argument is associated with the class metaobject. These values can then be accessed by calling the corresponding generic function. The correspondences are as follows:

Initialization Argument   Generic Function


:direct-default-initargs  class-direct-default-initargs
:direct-slots             class-direct-slots            
:direct-superclasses      class-direct-superclasses     
:documentation            documentation                 
:name                     class-name                    


Initialization arguments and accessors for class metaobjects.    

Instances of the class standard-class support multiple inheritance and reinitialization. Instances of the class funcallable-standard-class support multiple inheritance and reinitialization. For forward referenced classes, all of the initialization arguments default to nil.

Since built-in classes cannot be created or reinitialized by the user, an error is signaled if initialize-instance or reinitialize-instance are called to initialize or reinitialize a derived instance of the class built-in-class.

Methods

It is not specified which methods provide the initialization and reinitialization behavior described above. Instead, the information needed to allow portable programs to specialize this behavior is presented as a set of restrictions on the methods a portable program can define. The model is that portable initialization methods have access to the class metaobject when either all or none of the specified initialization has taken effect.

These restrictions govern the methods that a portable program can define on the generic functions initialize-instance, reinitialize-instance, and shared-initialize. These restrictions apply only to methods on these generic functions for which the first specializer is a subclass of the class class. Other portable methods on these generic functions are not affected by these restrictions.

• Portable programs must not define methods on shared-initialize.
• For initialize-instance and reinitialize-instance:
• Portable programs must not define primary methods.
• Portable programs may define around-methods, but these must be extending, not overriding methods.
• Portable before-methods must assume that when they are run, none of the initialization behavior described above has been completed.
• Portable after-methods must assume that when they are run, all of the initialization behavior described above has been completed.

The results are undefined if any of these restrictions are violated.

Initialization of Generic Function Metaobjects

A generic function metaobject can be created by calling make-instance. The initialization arguments establish the definition of the generic function. A generic function metaobject can be redefined by calling reinitialize-instance. Some classes of generic function metaobject do not support redefinition; in these cases, reinitialize-instance signals an error.

Initialization of a generic function metaobject must be done by calling make-instance and allowing it to call initialize-instance. Reinitialization of a generic-function metaobject must be done by calling reinitialize-instance. Portable programs must not call initialize-instance directly to initialize a generic function metaobject. Portable programs must not call shared-initialize directly to initialize or reinitialize a generic function metaobject. Portable programs must not call change-class to change the class of any generic function metaobject or to turn a non-generic-function object into a generic function metaobject.

Since metaobject classes may not be redefined, no behavior is specified for the result of calls to update-instance-for-redefined-class on generic function metaobjects. Since the class of a generic function metaobject may not be changed, no behavior is specified for the results of calls to update-instance-for-different-class on generic function metaobjects.

During initialization or reinitialization, each initialization argument is checked for errors and then associated with the generic function metaobject. The value can then be accessed by calling the appropriate accessor as shown in Table gf-mo-initargs.

This section begins with a description of the error checking and processing of each initialization argument. This is followed by a table showing the generic functions that can be used to access the stored initialization arguments. The section ends with a set of restrictions on portable methods affecting generic function metaobject initialization and reinitialization.

In these descriptions, the phrase "this argument defaults to value" means that when that initialization argument is not supplied, initialization or reinitialization is performed as if value had been supplied. For some initialization arguments this could be done by the use of default initialization arguments, but whether it is done this way is not specified. Implementations are free to define default initialization arguments for specified generic function metaobject classes. Portable programs are free to define default initialization arguments for portable subclasses of the class generic-function.

Unless there is a specific note to the contrary, then during reinitialization, if an initialization argument is not supplied, the previously stored value is left unchanged.

• The :argument-precedence-order argument is a list of symbols.
  
  An error is signaled if this argument appears but the :lambda-list argument does not appear. An error is signaled if this value is not a proper list or if this value is not a permutation of the symbols from the required arguments part of the :lambda-list initialization argument.
  
  When the generic function is being initialized or reinitialized, and this argument is not supplied, but the :lambda-list argument is supplied, this value defaults to the symbols from the required arguments part of the :lambda-list argument, in the order they appear in that argument. If neither argument is supplied, neither are initialized (see the description of :lambda-list.)
• The :declarations argument is a list of declarations.
  
  An error is signaled if this value is not a proper list or if each of its elements is not a legal declaration.
  
  When the generic function is being initialized, and this argument is not supplied, it defaults to the empty list.
• The :documentation argument is a string or nil.
  
  An error is signaled if this value is not a string or nil.
  
  If the generic function is being initialized, this argument defaults to nil.
• The :lambda-list argument is a lambda list.
  
  An error is signaled if this value is not a proper generic function lambda list.
  
  When the generic function is being initialized, and this argument is not supplied, the generic function's lambda list is not initialized. The lambda list will be initialized later, either when the first method is added to the generic function, or a later reinitialization of the generic function.
• The :method-combination argument is a method combination metaobject.
• The :method-class argument is a class metaobject.
  
  An error is signaled if this value is not a subclass of the class method.
  
  When the generic function is being initialized, and this argument is not supplied, it defaults to the class standard-method.
• The :name argument is an object.
  
  If the generic function is being initialized, this argument defaults to nil.

After the processing and defaulting of initialization arguments described above, the value of each initialization argument is associated with the generic function metaobject. These values can then be accessed by calling the corresponding generic function. The correspondences are as follows:

Initialization Argument     Generic Function


:argument-precedence-order  generic-function-argument-precedence-order
:declarations               generic-function-declarations 
:documentation              documentation                  
:lambda-list                generic-function-lambda-list   
:method-combination         generic-function-method-combination
:method-class               generic-function-method-class  
:name                       generic-function-name          


Initialization arguments and accessors for generic function metaobjects.    

Methods

It is not specified which methods provide the initialization and reinitialization behavior described above. Instead, the information needed to allow portable programs to specialize this behavior is presented as a set of restrictions on the methods a portable program can define. The model is that portable initialization methods have access to the generic function metaobject when either all or none of the specified initialization has taken effect.

These restrictions govern the methods that a portable program can define on the generic functions initialize-instance, reinitialize-instance, and shared-initialize. These restrictions apply only to methods on these generic functions for which the first specializer is a subclass of the class generic-function. Other portable methods on these generic functions are not affected by these restrictions.

• Portable programs must not define methods on shared-initialize.
• For initialize-instance and reinitialize-instance:
  • Portable programs must not define primary methods.
  • Portable programs may define around-methods, but these must be extending, not overriding methods.
  • Portable before-methods must assume that when they are run, none of the initialization behavior described above has been completed.
  • Portable after-methods must assume that when they are run, all of the initialization behavior described above has been completed.

The results are undefined if any of these restrictions are violated.

Initialization of Method Metaobjects

A method metaobject can be created by calling make-instance. The initialization arguments establish the definition of the method. A method metaobject cannot be redefined; calling reinitialize-instance signals an error.

Initialization of a method metaobject must be done by calling make-instance and allowing it to call initialize-instance. Portable programs must not call initialize-instance directly to initialize a method metaoject. Portable programs must not call shared-initialize directly to initialize a method metaobject. Portable programs must not call change-class to change the class of any method metaobject or to turn a non-method object into a method metaobject.

Since metaobject classes may not be redefined, no behavior is specified for the result of calls to update-instance-for-redefined-class on method metaobjects. Since the class of a method metaobject cannot be changed, no behavior is specified for the result of calls to update-instance-for-different-class on method metaobjects.

During initialization, each initialization argument is checked for errors and then associated with the method metaobject. The value can then be accessed by calling the appropriate accessor as shown in Table method-mo-initargs.

This section begins with a description of the error checking and processing of each initialization argument. This is followed by a table showing the generic functions that can be used to access the stored initialization arguments. The section ends with a set of restrictions on portable methods affecting method metaobject initialization.

In these descriptions, the phrase "this argument defaults to value" means that when that initialization argument is not supplied, initialization is performed as if value had been supplied. For some initialization arguments this could be done by the use of default initialization arguments, but whether it is done this way is not specified. Implementations are free to define default initialization arguments for specified method metaobject classes. Portable programs are free to define default initialization arguments for portable subclasses of the class method.

• The :qualifiers argument is a list of method qualifiers. An error is signaled if this value is not a proper list, or if any element of the list is not a non-null atom. This argument defaults to the empty list.
• The :lambda-list argument is the unspecialized lambda list of the method. An error is signaled if this value is not a proper lambda list. If this value is not supplied, an error is signaled.
• The :specializers argument is a list of the specializer metaobjects for the method. An error is signaled if this value is not a proper list, or if the length of the list differs from the number of required arguments in the :lambda-list argument, or if any element of the list is not a specializer metaobject. If this value is not supplied, an error is signaled.
• The :function argument is a method function. It must be compatible with the methods on compute-effective-method defined for this class of method and generic function with which it will be used. That is, it must accept the same number of arguments as all uses of call-method that will call it supply. (See compute-effective-method for more information.) An error is signaled if this argument is not supplied.
• When the method being initialized is an instance of a subclass of standard-accessor-method, the :slot-definition initialization argument must be provided. Its value is the direct slot definition metaobject which defines this accessor method. An error is signaled if the value is not an instance of a subclass of direct-slot-definition.
• The :documentation argument is a string or nil. An error is signaled if this value is not a string or nil. This argument defaults to nil.

After the processing and defaulting of initialization arguments described above, the value of each initialization argument is associated with the method metaobject. These values can then be accessed by calling the corresponding generic function. The correspondences are as follows:

Initialization Argument  Generic Function                


:qualifiers              method-qualifiers               
:lambda-list             method-lambda-list              
:specializers            method-specializers             
:function                method-function                 
:slot-definition         accessor-method-slot-definition 
:documentation           documentation                   


Initialization arguments and accessors for method metaobjects.    

Methods

It is not specified which methods provide the initialization behavior described above. Instead, the information needed to allow portable programs to specialize this behavior is presented in as a set of restrictions on the methods a portable program can define. The model is that portable initialization methods have access to the method metaobject when either all or none of the specified initialization has taken effect.

These restrictions govern the methods that a portable program can define on the generic functions initialize-instance, reinitialize-instance, and shared-initialize. These restrictions apply only to methods on these generic functions for which the first specializer is a subclass of the class method. Other portable methods on these generic functions are not affected by these restrictions.

• Portable programs must not define methods on shared-initialize or reinitialize-instance
• For initialize-instance:
  • Portable programs must not define primary methods.
  • Portable programs may define around-methods, but these must be extending, not overriding methods.
  • Portable before-methods must assume that when they are run, none of the initialization behavior described above has been completed.
  • Portable after-methods must assume that when they are run, all of the initialization behavior described above has been completed.

The results are undefined if any of these restrictions are violated.

Initialization of Slot Definition Metaobjects

A slot definition metaobject can be created by calling make-instance. The initialization arguments establish the definition of the slot definition. A slot definition metaobject cannot be redefined; calling reinitialize-instance signals an error.

Initialization of a slot definition metaobject must be done by calling make-instance and allowing it to call initialize-instance. Portable programs must not call initialize-instance directly to initialize a slot definition metaobject. Portable programs must not call shared-initialize directly to initialize a slot definition metaobject. Portable programs must not call change-class to change the class of any slot definition metaobject or to turn a non-slot-definition object into a slot definition metaobject.

Since metaobject classes may not be redefined, no behavior is specified for the result of calls to update-instance-for-redefined-class on slot definition metaobjects. Since the class of a slot definition metaobject cannot be changed, no behavior is specified for the result of calls to update-instance-for-different-class on slot definition metaobjects.

During initialization, each initialization argument is checked for errors and then associated with the slot definition metaobject. The value can then be accessed by calling the appropriate accessor as shown in Table slotd-mo-initargs.

This section begins with a description of the error checking and processing of each initialization argument. This is followed by a table showing the generic functions that can be used to access the stored initialization arguments.

In these descriptions, the phrase "this argument defaults to value" means that when that initialization argument is not supplied, initialization is performed as if value had been supplied. For some initialization arguments this could be done by the use of default initialization arguments, but whether it is done this way is not specified. Implementations are free to define default initialization arguments for specified slot definition metaobject classes. Portable programs are free to define default initialization arguments for portable subclasses of the class slot-definition.

• The :name argument is a slot name. An error is signaled if this argument is not a symbol which can be used as a variable name. An error is signaled if this argument is not supplied.
• The :initform argument is a form. The :initform argument defaults to nil. An error is signaled if the :initform argument is supplied, but the :initfunction argument is not supplied.
• The :initfunction argument is a function of zero arguments which, when called, evaluates the :initform in the appropriate lexical environment. The :initfunction argument defaults to false. An error is signaled if the :initfunction argument is supplied, but the :initform argument is not supplied.
• The :type argument is a type specifier name. An error is signaled otherwise. The :type argument defaults to the symbol t.
• The :allocation argument is a symbol. An error is signaled otherwise. The :allocation argument defaults to the symbol :instance.
• The :initargs argument is a list of symbols. An error is signaled if this argument is not a proper list, or if any element of this list is not a symbol. The :initargs argument defaults to the empty list.
• The :readers argument is a list of function names. An error is signaled if it is not a proper list, or if any element is not a valid function name. It defaults to the empty list. An error is signaled if this argument is supplied and the metaobject is not a direct slot definition.
• The :writers argument is a list of function names. An error is signaled if it is not a proper list, or if any element is not a valid function name. It defaults to the empty list. An error is signaled if this argument is supplied and the metaobject is not a direct slot definition.
• The :documentation argument is a string or nil. An error is signaled otherwise. The :documentation argument defaults to nil.

After the processing and defaulting of initialization arguments described above, the value of each initialization argument is associated with the slot definition metaobject. These values can then be accessed by calling the corresponding generic function. The correspondences are as follows:

Initialization Argument Generic Function


:name                   slot-definition-name         
:initform               slot-definition-initform      
:initfunction           slot-definition-initfunction  
:type                   slot-definition-type          
:allocation             slot-definition-allocation    
:initargs               slot-definition-initargs      
:readers                slot-definition-readers       
:writers                slot-definition-writers       
:documentation          documentation                 


Initialization arguments and accessors for slot definition metaobjects.    

Methods

It is not specified which methods provide the initialization and reinitialization behavior described above. Instead, the information needed to allow portable programs to specialize this behavior is presented as a set of restrictions on the methods a portable program can define. The model is that portable initialization methods have access to the slot definition metaobject when either all or none of the specified initialization has taken effect.

These restrictions govern the methods that a portable program can define on the generic functions initialize-instance, reinitialize-instance, and shared-initialize. These restrictions apply only to methods on these generic functions for which the first specializer is a subclass of the class slot-definition. Other portable methods on these generic functions are not affected by these restrictions.

• Portable programs must not define methods on shared-initialize or reinitialize-instance.
• For initialize-instance:
  • Portable programs must not define primary methods.
  • Portable programs may define around-methods, but these must be extending, not overriding methods.
  • Portable before-methods must assume that when they are run, none of the initialization behavior described above has been completed.
  • Portable after-methods must assume that when they are run, all of the initialization behavior described above has been completed.

The results are undefined if any of these restrictions are violated.

Readers for Class Metaobjects

In this and the immediately following sections, the "reader" generic functions which simply return information associated with a particular kind of metaobject are presented together. General information is presented first, followed by a description of the purpose of each, and ending with the specified methods for these generic functions.

The reader generic functions which simply return information associated with class metaobjects are presented together in this section.

Each of the reader generic functions for class metaobjects has the same syntax, accepting one required argument called class, which must be an class metaobject; otherwise, an error is signaled. An error is also signaled if the class metaobject has not been initialized.

These generic functions can be called by the user or the implementation.

For any of these generic functions which returns a list, such lists will not be mutated by the implementation. The results are undefined if a portable program allows such a list to be mutated.

standard-class    forward-     built-in-
and               referenced-  class
funcallable-      class        
standard-class                 


class-default-initargs         2   3   4 
class-direct-default-initargs  1   4   4 
class-direct-slots             1   4   4 
class-direct-subclasses        9   9   7 
class-direct-superclasses      1   4   7 
class-finalized-p              2   6   5 
class-name                     1   1   8 
class-precedence-list          2   3   7 
class-prototype               10  10  10 
class-slots                    2   3   4     

1. This method returns the value which was associated with the class metaobject during initialization or reinitialization.
2. This method returns the value associated with the class metaobject by finalize-inheritance (standard-class) or finalize-inheritance (funcallable-standard-class)
3. This method signals an error.
4. This method returns the empty list.
5. This method returns true.
6. This method returns false.
7. This method returns a value derived from the information in Table inherit-struct-figure, except that implementation-specific modifications are permitted as described in section "Implementation and User Specialization."
8. This method returns the name of the built-in class.
9. This methods returns a value which is maintained by add-direct-subclass (class class) and remove-direct-subclass (class class). This method can be overridden only if those methods are overridden as well.
10. No behavior is specified for this method beyond that specified for the generic function.

Readers for Generic Function Metaobjects

The reader generic functions which simply return information associated with generic function metaobjects are presented together in this section.

Each of the reader generic functions for generic function metaobjects has the same syntax, accepting one required argument called generic-function, which must be a generic function metaobject; otherwise, an error is signaled. An error is also signaled if the generic function metaobject has not been initialized.

These generic functions can be called by the user or the implementation.

The list returned by this generic function will not be mutated by the implementation. The results are undefined if a portable program mutates the list returned by this generic function.

Readers for Method Metaobjects

The reader generic functions which simply return information associated with method metaobjects are presented together here in the format described under "Readers for Class Metaobjects."

Each of these reader generic functions have the same syntax, accepting one required argument called method, which must be a method metaobject; otherwise, an error is signaled. An error is also signaled if the method metaobject has not been initialized.

These generic functions can be called by the user or the implementation.

For any of these generic functions which returns a list, such lists will not be mutated by the implementation. The results are undefined if a portable program allows such a list to be mutated.

Readers for Slot Definition Metaobjects

The reader generic functions which simply return information associated with slot definition metaobjects are presented together here in the format described under "Readers for Class Metaobjects."

Each of the reader generic functions for slot definition metaobjects has the same syntax, accepting one required argument called slot, which must be a slot definition metaobject; otherwise, an error is signaled. An error is also signaled if the slot definition metaobject has not been initialized.

These generic functions can be called by the user or the implementation.

For any of these generic functions which returns a list, such lists will not be mutated by the implementation. The results are undefined if a portable program allows such a list to be mutated.

Generic Functions









Direct Slot Definition Metaobjects

The following additional reader generic functions are defined for direct slot definition metaobjects.





Effective Slot Definition Metaobjects

The following reader generic function is defined for effective slot definition metaobjects.