Skip to main content

6.1 Sections

Chapter 6 Sections

Chapter 6 Sections​

6.1.2 Initialization of class metaobjects​

Initialization of Class Metaobjects

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 the table below. (FIXME:insert anchor)

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.

Comments and remarks​

This section is named Initialization of Class Metaobjects and appears in Chapter 6 (Generic functions and methods) of the original text. There is a section with the same name in Chapter 5 (Concepts) of the original text. When sections are referred to in the text, it is not specified which one.

6.1.3 Initialization of generic function metaobjects​

Initialization of Generic Function Metaobjects

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 the table below. (FIXME:insert anchor).

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. (But see the note at the end of this page. [RS])

  • The :method-class argument is a class metaobject. (But see the note at the end of this page. [RS])

    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

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.

Note:

Nowhere in the chain of functions that initialize generic-function metaobjects is any defaulting behavior for method-combination metaobjects defined. One possible solution to this dilemma is to implement that defaulting behavior here, so that if the :method-combination keyword argument is not supplied, then it defaults to the standard method combination. [RS]

6.1.4 Initialization of method metaobjects​

Initialization of Method Metaobjects

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 the table below (FIXME: insert anchor reference).

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

6.1.5 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 the table below.

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 arguments and accessors for slot definition metaobjects.

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

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.

6.1.6 Readers for class metaobjects​

readers for Class Metaobjects

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.

Functions​

Generic Function class-default-initargs Generic Function class-direct-default-initargs Generic Function class-direct-slots Generic Function class-direct-subclasses Generic Function class-direct-superclasses Generic Function class-finalized-p Generic Function class-name Generic Function class-precedence-list Generic Function class-prototype Generic Function class-slots

Methods​

The specified methods for the class metaobject reader generic functions are presented below.

Each entry in the table indicates a method on one of the reader generic functions, specialized to a specified class. The number in each entry is a reference to the full description of the method. The full descriptions appear after the table.

standard-class an forward-reference built-in-class d d-class

funcallable-stand ard-class

class-default-ini 2 3 4 targs

class-direct-defa 1 4 4 ult-initargs

class-direct-slot 1 4 4 s

class-direct-subc 9 9 7 lasses

class-direct-supe 1 4 7 rclasses

class-finalized-p 2 6 5

class-name 1 1 8

class-precedence- 2 3 7 list

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 (class standard-class) or finalize-inheritance (class 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 [this table](/meta-object-protocol/table-class-inheritance), 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 (superclass class) (subclass class) and remove-direct-subclass (superclass class) (subclass 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.

Comments and remarks​

It is not clear what is meant by the phrase "Each entry in the table indicates a method on one of the reader generic functions" above. It clearly does not mean that each number represents one method, because the same number appears in different rows of the table. One interpretation is that there are exactly 30 methods, but this can not be the case because the specification does not mention a common superclass for standard-class and funcallable-standard-class, so there can not be a single method for the two. Another interpretation, then, is that there are exactly 40 methods. However, in other parts of the document, there is mention of a single method specialized for class that does not correspond to the table above.

6.1.7 Readers for generic function metaobjects​

Readers for Generic Function Metaobjects

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.

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.

Functions​

Generic Function generic-function-argument-precedence-order Generic Function generic-function-declarations Generic Function generic-function-lambda-list Generic Function generic-function-method-class Generic Function generic-function-method-combination Generic Function generic-function-methods Generic Function generic-function-name

Methods​

The specified methods for the generic function metaobject reader generic functions are presented below.

Method generic-function-argument-precedence-order (generic-function standard-generic-function) Method generic-function-declarations (generic-function standard-generic-function) Method generic-function-lambda-list (generic-function standard-generic-function) Method generic-function-method-class (generic-function standard-generic-function) Method generic-function-method-combination (generic-function standard-generic-function) Method generic-function-name (generic-function standard-generic-function)

No behavior is specified for these methods beyond that which is specified for their respective generic functions.

Method generic-function-methods (generic-function standard-generic-function)

No behavior is specified for this method beyond that which is specified for their respective generic functions.

The value returned by this method is maintained by add-method (generic-function standard-generic-function) (method standard-method) and remove-method (generic-function standard-generic-function) (method standard-method).

Comments and remarks​

The fourth paragraph of the original text reads like this:

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.

But we think this is an editing error because there is not a single generic function being referred to, rather several generic functions. For that reason, we copied a similar paragraph from the previous section in the book.

6.1.8 Readers for method metaobjects​

Readers for Method Metaobjects

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.

Functions​

Generic Function method-function Generic Function method-generic-function Generic Function method-lambda-list Generic Function method-specializers Generic Function method-qualifiers Generic Function accessor-method-slot-definition

Methods​

The specified methods for the method metaobject reader generic functions are presented below.

Method method-function (method standard-method) Method method-lambda-list (method standard-method) Method method-specializers (method standard-method) Method method-qualifiers (method standard-method)

No behavior is specified for these methods beyond that which is specified for their respective generic functions.

Method method-generic-function (method standard-method)

No behavior is specified for this method beyond that which is specified for their respective generic functions.

The value returned by this method is maintained by add-method (generic-function standard-generic-function) (method standard-method) and remove-method (generic-function standard-generic-function) (method standard-method).

Method accessor-method-slot-definition (method standard-accessor-method)

No behavior is specified for this method beyond that which is specified for their respective generic functions.

6.1.9 Readers for slot definition metaobjects​

Readers for Slot Definition Metaobjects

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.

Functions​

Generic Function slot-definition-allocation Generic Function slot-definition-initargs Generic Function slot-definition-initform Generic Function slot-definition-initfunction Generic Function slot-definition-name Generic Function slot-definition-type

Methods​

The specified methods for the slot definition metaobject reader generic functions are presented below.

Method slot-definition-allocation (slot standard-slot-definition) Method slot-definition-initargs (slot standard-slot-definition) Method slot-definition-initform (slot standard-slot-definition) Method slot-definition-initfunction (slot standard-slot-definition) Method slot-definition-name (slot standard-slot-definition) Method slot-definition-type (slot standard-slot-definition)

No behavior is specified for these methods beyond that which is specified for their respective generic functions.

Readers for Direct Slot Definition Metaobjects​

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

Functions​

Generic Function slot-definition-readers Generic Function slot-definition-writers

Methods​

Method slot-definition-readers (direct-slot standard-direct-slot-definition) Method slot-definition-writers (direct-slot standard-direct-slot-definition)

No behavior is specified for this method beyond that which is specified for their respective generic functions.

Readers for Effective Slot Definition Metaobjects​

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

Functions​

Generic Function slot-definition-location

Methods​

Method slot-definition-location (effective-slot-definition standard-effective-slot-definition)