29.4. Slot Definitions
Prev | Chapter 29. Meta-Object Protocol | Next

## 29.4. Slot Definitions

### 29.4.1. Inheritance Structure of slot definition metaobject Classes

Figure 29.3. 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 `SIGNAL`ed. An `ERROR` is also `SIGNAL`ed 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`

###### `(`CLOS:SLOT-DEFINITION-NAME` `slot`)`

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.

##### 29.4.2.1.2. Generic Function `CLOS:SLOT-DEFINITION-ALLOCATION`

###### `(`CLOS:SLOT-DEFINITION-ALLOCATION` `slot`)`

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.

##### 29.4.2.1.3. Generic Function `CLOS:SLOT-DEFINITION-INITFORM`

###### `(`CLOS:SLOT-DEFINITION-INITFORM` `slot`)`

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`).

##### 29.4.2.1.4. Generic Function `CLOS:SLOT-DEFINITION-INITFUNCTION`

###### `(`CLOS:SLOT-DEFINITION-INITFUNCTION` `slot`)`

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`

###### `(`CLOS:SLOT-DEFINITION-TYPE` `slot`)`

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.

##### 29.4.2.1.6. Generic Function `CLOS:SLOT-DEFINITION-INITARGS`

###### `(`CLOS:SLOT-DEFINITION-INITARGS` `slot`)`

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` `SIGNAL`s 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;
- ... call `SHARED-INITIALIZE` directly to initialize a slot definition metaobject;
- ... 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 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 `SIGNAL`ed if this argument is not a symbol which can be used as a variable name. An `ERROR` is `SIGNAL`ed 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 `SIGNAL`ed 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 `SIGNAL`ed if the `:INITFUNCTION` argument is supplied, but the `:INITFORM` argument is not supplied.
- The `:TYPE` argument is a type specifier name. An `ERROR` is `SIGNAL`ed otherwise. The `:TYPE` argument defaults to the symbol `T`.
- The `:ALLOCATION` argument is a `SYMBOL`. An `ERROR` is `SIGNAL`ed otherwise. The `:ALLOCATION` argument defaults to the symbol `:INSTANCE`.
- The `:INITARGS` argument is a `LIST` of `SYMBOL`s. An `ERROR` is `SIGNAL`ed 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 `LIST`s of function names. An `ERROR` is `SIGNAL`ed 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 `SIGNAL`ed 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 `SIGNAL`ed 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

Initialization Argument | Generic Function
--- | ---
`:NAME` | `CLOS:SLOT-DEFINITION-NAME`
`:INITFORM` | `CLOS:SLOT-DEFINITION-INITFORM`
`:INITFUNCTION` | `CLOS:SLOT-DEFINITION-INITFUNCTION`
`:TYPE` | `CLOS:SLOT-DEFINITION-TYPE`
`:ALLOCATION` | `CLOS:SLOT-DEFINITION-ALLOCATION`
`:INITARGS` | `CLOS:SLOT-DEFINITION-INITARGS`
`:READERS` | `CLOS:SLOT-DEFINITION-READERS`
`:WRITERS` | `CLOS:SLOT-DEFINITION-WRITERS`
`:DOCUMENTATION` | `DOCUMENTATION`

#### 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.45 | Last modified: 2008-05-14

Enter your search termsSubmit search form
Webclisp.cons.orgclisp.podval.orgwww.lisp.org

Prev | Up | Next
29.3. Classes | Home | 29.5. Generic Functions