29.4. Slot Definitions

29.4.1. Inheritance Structure of slot definition metaobject Classes
29.4.2. Introspection: Readers for slot definition metaobjects
29.4.2.1. Generic Functions
29.4.2.1.1. Generic Function CLOS:SLOT-DEFINITION-NAME
29.4.2.1.2. Generic Function CLOS:SLOT-DEFINITION-ALLOCATION
29.4.2.1.3. Generic Function CLOS:SLOT-DEFINITION-INITFORM
29.4.2.1.4. Generic Function CLOS:SLOT-DEFINITION-INITFUNCTION
29.4.2.1.5. Generic Function CLOS:SLOT-DEFINITION-TYPE
29.4.2.1.6. Generic Function CLOS:SLOT-DEFINITION-INITARGS
29.4.2.2. Methods
29.4.2.3. Readers for direct slot definition metaobjects
29.4.2.3.1. Generic Function CLOS:SLOT-DEFINITION-READERS
29.4.2.3.2. Generic Function CLOS:SLOT-DEFINITION-WRITERS
29.4.2.4. Readers for effective slot definition metaobjects
29.4.2.4.1. Generic Function CLOS:SLOT-DEFINITION-LOCATION
29.4.3. Initialization of slot definition metaobjects
29.4.3.1. Methods

29.4.1. Inheritance Structure of slot definition metaobject Classes

Figure 29.3. Inheritance structure of slot definition metaobject classes

Inheritance structure of slot definition metaobject classes

29.4.2. Introspection: 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 in Section 29.3.3, “Introspection: 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.

29.4.2.1. Generic Functions

29.4.2.1.1. Generic Function CLOS:SLOT-DEFINITION-NAME

Returns the name of slot. This value is a symbol that can be used as a variable name. This is the value of the :NAME initialization argument that was associated with the slot definition metaobject during initialization.

Implementation dependent: only in CLISP

The slot name does not need to be usable as a variable name. Slot names like NIL or T are perfectly valid.

Returns the allocation of slot. This is a symbol. This is the defaulted value of the :ALLOCATION initialization argument that was associated with the slot definition metaobject during initialization.

Returns the initialization form of slot. This can be any form. This is the defaulted value of the :INITFORM initialization argument that was associated with the slot definition metaobject during initialization. When slot has no initialization form, the value returned is unspecified (however, CLOS:SLOT-DEFINITION-INITFUNCTION is guaranteed to return NIL).

Returns the initialization function of slot. This value is either a function of no arguments, or NIL, indicating that the slot has no initialization function. This is the defaulted value of the :INITFUNCTION initialization argument that was associated with the slot definition metaobject during initialization.

29.4.2.1.5. Generic Function CLOS:SLOT-DEFINITION-TYPE

Returns the type of slot. This is a type specifier name. This is the defaulted value of the :TYPE initialization argument that was associated with the slot definition metaobject during initialization.

Returns the set of initialization argument keywords for slot. This is the defaulted value of the :INITARGS initialization argument that was associated with the slot definition metaobject during initialization.

29.4.2.2. Methods

The specified methods for the slot definition metaobject readers

(CLOS:SLOT-DEFINITION-NAME (slot-definition CLOS:STANDARD-SLOT-DEFINITION))
(CLOS:SLOT-DEFINITION-ALLOCATION (slot-definition CLOS:STANDARD-SLOT-DEFINITION))
(CLOS:SLOT-DEFINITION-INITFORM (slot-definition CLOS:STANDARD-SLOT-DEFINITION))
(CLOS:SLOT-DEFINITION-INITFUNCTION (slot-definition CLOS:STANDARD-SLOT-DEFINITION))
(CLOS:SLOT-DEFINITION-TYPE (slot-definition CLOS:STANDARD-SLOT-DEFINITION))
(CLOS:SLOT-DEFINITION-INITARGS (slot-definition CLOS:STANDARD-SLOT-DEFINITION))
No behavior is specified for these methods beyond that which is specified for their respective generic functions.

29.4.2.3. Readers for direct slot definition metaobjects

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

29.4.2.3.1. Generic Function CLOS:SLOT-DEFINITION-READERS
(CLOS:SLOT-DEFINITION-READERS direct-slot-definition)

Returns a (possibly empty) set of readers of the direct-slot-definition. This value is a list of function names. This is the defaulted value of the :READERS initialization argument that was associated with the direct slot definition metaobject during initialization.

29.4.2.3.2. Generic Function CLOS:SLOT-DEFINITION-WRITERS
(CLOS:SLOT-DEFINITION-WRITERS direct-slot-definition)

Returns a (possibly empty) set of writers of the direct-slot-definition. This value is a list of function names. This is the defaulted value of the :WRITERS initialization argument that was associated with the direct slot definition metaobject during initialization.

(CLOS:SLOT-DEFINITION-READERS (direct-slot-definition CLOS:STANDARD-DIRECT-SLOT-DEFINITION))
(CLOS:SLOT-DEFINITION-WRITERS (direct-slot-definition CLOS:STANDARD-DIRECT-SLOT-DEFINITION))
No behavior is specified for these methods beyond that which is specified for their respective generic functions.

29.4.2.4. Readers for effective slot definition metaobjects

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

29.4.2.4.1. Generic Function CLOS:SLOT-DEFINITION-LOCATION
(CLOS:SLOT-DEFINITION-LOCATION effective-slot-definition)

Returns the location of effective-slot-definition. The meaning and interpretation of this value is described in Section 29.10.1, “Instance Structure Protocol”.

(CLOS:SLOT-DEFINITION-LOCATION (effective-slot-definition CLOS:STANDARD-EFFECTIVE-SLOT-DEFINITION))
This method returns the value stored by CLOS:COMPUTE-SLOTS :AROUND (STANDARD-CLASS) and CLOS:COMPUTE-SLOTS :AROUND (CLOS:FUNCALLABLE-STANDARD-CLASS).

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

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 29.3, “Initialization arguments and accessors for slot definition metaobjects”.

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

    Implementation dependent: only in CLISP

    The :NAME argument does not need to be usable as a variable name. Slot names like NIL or T are perfectly valid.

  • 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 and :WRITERS arguments are LISTs of function names. An ERROR is SIGNALed if they are not proper lists, or if any element is not a valid function name. They default to the empty list. An ERROR is SIGNALed if either of these arguments is supplied and the metaobject is not a CLOS:DIRECT-SLOT-DEFINITION.
  • The :DOCUMENTATION argument is a STRING or NIL. An ERROR is SIGNALed if it is not. This argument default to NIL during initialization.

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:

Table 29.3. Initialization arguments and accessors for slot definition metaobjects


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


These notes document CLISP version 2.49Last modified: 2010-07-07