4. Types and Classes

• 4.1 Introduction
• 4.2 Types
• 4.3 Classes
• Dictionary

4.1 Introduction#

2.0.0 4 6.2.1 1A type is a (possibly infinite) set of objects. An object can belong to more than one type. Types are never explicitly represented as objects by Common Lisp. Instead, they are referred to indirectly by the use of type specifiers, which are objects that denote types.

New types can be defined using deftype, defstruct, defclass, and define-condition.

The function typep, a set membership test, is used to determine whether a given object is of a given type. The function subtypep, a subset test, is used to determine whether a given type is a subtype of another given type. The function type-of returns a particular type to which a given object belongs, even though that object must belong to one or more other types as well. (For example, every object is of type t, but type-of always returns a type specifier for a type more specific than t.)

2.0.0 1Objects, not variables, have types. Normally, any variable can have any object as its value. It is possible to declare that a variable takes on only values of a given type by making an explicit type declaration. 2.0.0 5Types are arranged in a directed acyclic graph, except for the presence of equivalences.

Declarations can be made about types using declare, proclaim, declaim, or the. For more information about declarations, see Section 3.3 (Declarations).

Among the fundamental objects of the object system are classes. A class determines the structure and behavior of a set of other objects, which are called its instances. Every object is a direct instance of a class. The class of an object determines the set of operations that can be performed on the object. For more information, see Section 4.3 (Classes).

It is possible to write functions that have behavior specialized to the class of the objects which are their arguments. For more information, see Section 7.6 (Generic Functions and Methods).

The class of the class of an object is called its metaclass. For more information about metaclasses, see Section 7.4 (Meta-Objects).

4.2 Types#

At Barmar's suggestion, and by consensus of Quinquevirate, the type hierarchy diagrams, which were quite hard to maintain and anyway unnecessary, were removed. The removed text is in Stony-Brook.SCRC.Symbolics.COM:>ANSI-CL>spec>archive>source>type-hierarchy-diagrams.tex -kmp 10-Jun-91

4.2.1 Data Type Definition#

!!! Insert table of Type Specifiers like AND, OR, NOT... from top of DICT-TYPES ? -kmp 17-Oct-91

4.2.2 Type Relationships#

• The types cons, symbol, array, number, character, hash-table, function, readtable, package, pathname, stream, random-state, condition, restart, and any single other type created by defstruct, Added per suggestion of Barrett: define-condition, or defclass are pairwise disjoint, except for type relations explicitly established by specifying superclasses in defclass or define-condition or the :include option of defstruct.

  The following will be left out of the standard. 2.15.0 6 \itemitem{\bull} \typeref{Cons}, \typeref{symbol}, \typeref{array}, \typeref{number}, and \typeref{character} are \term{pairwise} \term{disjoint}.

  The following will be left out of the standard. 2.15.0 27 \itemitem{\bull} \typeref{hash-table}, \typeref{readtable}, \typeref{package}, \typeref{pathname}, \typeref{stream}, and \typeref{random-state} are \term{pairwise} \term{disjoint}.

  2.15.0 28

• Any two types created by defstruct are disjoint unless one is a supertype of the other by virtue of the defstruct :include option.

  Editor: KMP: The comments in the source say gray suggested some change from “common superclass” to “common subclass” in the following, but the result looks suspicious to me. !!! Barrett says: It fits the glossary definition of disjoint, i.e., no common elements. However, I think that is broken. In places where we have specified disjointness requirements, all we really seem to be intendeing is that two types C1 and C2 are disjoint if neither is a subtype of the other.

• Any two distinct classes created by defclass added --sjl 7 Mar 92or define-condition are disjoint unless they have a common subclass or one class is a subclass of the other. The preceding text by Moon replaces the following... "common superclass" changed to "common subclass" as suggested by Gray \itemitem{\bull} Any two \term{classes} created by \macref{defclass} are \term{disjoint} unless they have a common \term{subclass} or one \term{class} is a \term{superclass} of the other. Any two \term{classes} created by \macref{defclass} are \term{disjoint} unless they have a common \term{superclass}." {That assumes that our definition of superclass says every class is a superclass of itself, which I think is the case, but did not check.} RPG suggestion follows: \itemitem{\bull} Any type created by defstruct or defclass is guaranteed to be disjoint from all other types unless subclass or :include is used.

  The following will be deleted from the standard: 2.15.0 29 \itemitem{\bull} An \term{exhaustive union} for \thetype{common} is formed by \typeref{cons}, \typeref{symbol}, \f{(array x)} where \f{x} is either \typeref{t} or a \term{subtype} of \typeref{common}, \typeref{string}, \typeref{fixnum}, \typeref{bignum}, \typeref{ratio}, \typeref{short-float}, \typeref{single-float}, \typeref{double-float}, \typeref{long-float}, \f{(complex x)} where \f{x} is a \term{subtype} of \typeref{common}, \typeref{standard-char}, \typeref{hash-table}, \typeref{readtable}, \typeref{package}, \typeref{pathname}, \typeref{stream}, \typeref{random-state}, and all \term{types} created by the user via \macref{defstruct}. An implementation cannot add \term{subtypes} to \typeref{common}.

  Following is suggested by Moon, rewording of a clause in 88-002R.

• An implementation may be extended to add other subtype relationships between the specified types, as long as they do not violate the type relationships and disjointness requirements specified here. An implementation may define additional types that are subtypes or supertypes of any specified types, as long as each additional type is a subtype of type t and a supertype of type nil and the disjointness requirements are not violated.

  At the discretion of the implementation, either standard-object or structure-object might appear in any class precedence list for a system class that does not already specify either standard-object or structure-object. If it does, it must precede the class t and follow all other standardized classes.

Type Specifiers

4.2.3 Type Specifiers#

Discussion of difference between "type specifiers for declaration" and "type specifiers for discrimination" removed.

4.1.0 1Type specifiers can be symbols, classes, or lists. Figure 4–2 lists symbols that are standardized atomic type specifiers, and Figure 4–3 lists standardized compound type specifier names. For syntax information, see the dictionary entry for the corresponding type specifier. It is possible to define new type specifiers using defclass, define-condition, defstruct, or deftype.

4.3.0 4

4.2.0 1If a type specifier is a list, the car of the list is a symbol, and the rest of the list is subsidiary type information. Such a type specifier is called a compound type specifier. Except as explicitly stated otherwise, the subsidiary items can be unspecified. The unspecified subsidiary items are indicated by writing *. For example, to completely specify a vector, the type of the elements and the length of the vector must be present.

 (vector double-float 100)

 (vector double-float *)

 (vector * 100)                                      

4.2.0 2If a list has one or more unspecified items at the end, those items can be dropped. If dropping all occurrences of * results in a singleton list, then the parentheses can be dropped as well (the list can be replaced by the symbol in its car). For example, (vector double-float *) can be abbreviated to (vector double-float), and (vector * *) can be abbreviated to (vector) and then to vector.

Syntax info removed to make the document smaller and more modular. -kmp 20-Oct-91 Added CONS per Dalton #10 (first public review). -kmp 10-May-93

The next figure show the defined names that can be used as compound type specifier names but that cannot be used as atomic type specifiers.

4.7.0 1New type specifiers can come into existence in two ways.

• Defining a structure by using defstruct without using the :type specifier or defining a class by using defclass added --sjl 7 Mar 92 or define-condition automatically causes the name of the structure or class to be a new type specifier symbol.
• deftype can be used to define derived type specifiers, which act as `abbreviations' for other type specifiers.

A class object can be used as a type specifier. When used this way, it denotes the set of all members of that class.

The next figure shows some defined names relating to types and declarations.

I added SUBTYPEP, TYPEP, DEFINE-CONDITION. --sjl 7 Mar 92

The next figure shows all defined names that are type specifier names, whether for atomic type specifiers or compound type specifiers; this list is the union of the lists in Figure 4–2 and Figure 4–3.

4.3 Classes#

While the object system is general enough to describe all standardized classes (including, for example, number, hash-table, and symbol), the next figure contains a list of classes that are especially relevant to understanding the object system.

4.3.1 Introduction to Classes#

A class can inherit structure and behavior from other classes. A class whose definition refers to other classes for the purpose of inheriting from them is said to be a subclass of each of those classes. The classes that are designated for purposes of inheritance are said to be superclasses of the inheriting class.

A class can have a name. The function class-name takes a class object and returns its name. The name of an anonymous class is nil. A symbol can name a class. The function find-class takes a symbol and returns the class that the symbol names. A class has a proper name if the name is a symbol and if the name of the class names that class. That is, a class $C$ has the proper name $S$ if $S=$ (class-name $C$) and $C=$ (find-class $S$). Notice that it is possible for (find-class $S_1$) $=$ (find-class $S_2$) and $S_1\ne S_2$. If $C=$ (find-class $S$), we say that $C$ is the class named $S$.

A class $C_1$ is a direct superclass of a class $C_2$ if $C_2$ explicitly designates $C_1$ as a superclass in its definition. In this case $C_2$ is a direct subclass of $C_1$. A class $C_n$ is a superclass of a class $C_1$ if there exists a series of classes $C_2,\dots ,C_{n-1}$ such that $C_{i+1}$ is a direct superclass of $C_i$ for $1\le i<n$. In this case, $C_1$ is a subclass of $C_n$. A class is considered neither a superclass nor a subclass of itself. That is, if $C_1$ is a superclass of $C_2$, then $C_1\ne C_2$. The set of classes consisting of some given class $C$ along with all of its superclasses is called “$C$ and its superclasses.”

Each class has a class precedence list, which is a total ordering on the set of the given class and its superclasses. The total ordering is expressed as a list ordered from most specific to least specific. The class precedence list is used in several ways. In general, more specific classes can shadow₁ features that would otherwise be inherited from less specific classes. The method selection and combination process uses the class precedence list to order methods from most specific to least specific.

When a class is defined, the order in which its direct superclasses are mentioned in the defining form is important. Each class has a local precedence order, which is a list consisting of the class followed by its direct superclasses in the order mentioned in the defining form.

A class precedence list is always consistent with the local precedence order of each class in the list. The classes in each local precedence order appear within the class precedence list in the same order. If the local precedence orders are inconsistent with each other, no class precedence list can be constructed, and an error is signaled. The class precedence list and its computation is discussed in Section 4.3.6 (Determining the Class Precedence List).

classes are organized into a directed acyclic graph. There are two distinguished classes, named t and standard-object. The class named t has no superclasses. It is a superclass of every class except itself. The class named standard-object is an instance of the class standard-class and is a superclass of every class that is an instance of the class standard-class except itself.

Reviewer: Barmar: This or something like it needs to be said in the introduction.!!!There is a mapping from the object system class space into the type space. Many of the standard types specified in this document have a corresponding class that has the same name as the type. Some types do not have a corresponding class. The integration of the type and class systems is discussed in Section 4.3.8 (Integrating Types and Classes).

Classes are represented by objects that are themselves instances of classes. The class of the class of an object is termed the metaclass of that object. When no misinterpretation is possible, the term metaclass is used to refer to a class that has instances that are themselves classes. The metaclass determines the form of inheritance used by the classes that are its instances and the representation of the instances of those classes. The object system provides a default metaclass, standard-class, that is appropriate for most programs. The meta-object protocol provides mechanisms for defining and using new metaclasses.

Except where otherwise specified, all classes mentioned in this standard are instances of the class standard-class, all generic functions are instances of the class standard-generic-function, and all methods are instances of the class standard-method.

\beginsubsubsection{Metaclasses} ??? Is the following paragraph necessary in this specification??? The \newterm{metaclass} of an object is the class of its class. The metaclass determines the representation of instances of its instances and the forms of inheritance used by its instances for slot descriptions and method inheritance. The metaclass mechanism can be used to provide particular forms of optimization or to tailor the \CLOS\ for particular uses. The protocol for defining metaclasses is discussed in the chapter ``The \CLOS\ Meta-Object Protocol.'' \endsubsubsection%{Metaclasses}

4.3.2 Standard Metaclasses#

• The class standard-class is the default class of classes defined by defclass.

• The class built-in-class is the class whose instances are classes that have special implementations with restricted capabilities. Any class that corresponds to a standard type might be an instance of built-in-class. The predefined type specifiers that are required to have corresponding classes are listed in Figure 4–8. It is implementation-dependent whether each of these classes is implemented as a built-in class.

• All classes defined by means of defstruct are instances of the class structure-class.

4.3.3 Defining Classes#

The definition of a class includes:

• The name of the new class. For newly-defined classes this name is a proper name.

• The list of the direct superclasses of the new class.

• A set of slot specifiers. Each slot specifier includes the name of the slot and zero or more slot options. A slot option pertains only to a single slot. If a class definition contains two slot specifiers with the same name, an error is signaled.

• A set of class options. Each class option pertains to the class as a whole.

The slot options and class options of the defclass form provide mechanisms for the following:

• Supplying a default initial value form for a given slot.

• Requesting that methods for generic functions be automatically generated for reading or writing slots.

• Controlling whether a given slot is shared by all instances of the class or whether each instance of the class has its own slot.

• Supplying a set of initialization arguments and initialization argument defaults to be used in instance creation.

  \itemitem{\bull} Requesting that a constructor function be automatically generated for making instances of the new class.

• Indicating that the metaclass is to be other than the default. The :metaclass option is reserved for future use; an implementation can be extended to make use of the :metaclass option.

• Indicating the expected type for the value stored in the slot.

• Indicating the documentation string for the slot.

4.3.4 Creating Instances of Classes#

4.3.5 Inheritance#

A class can inherit methods, slots, and some defclass options from its superclasses. Other sections describe the inheritance of methods, the inheritance of slots and slot options, and the inheritance of class options.

4.3.5.1 Examples of Inheritance#

 (defclass C1 () 
     ((S1 :initform 5.4 :type number) 
      (S2 :allocation :class)))
 
 (defclass C2 (C1) 
     ((S1 :initform 5 :type integer)
      (S2 :allocation :instance)
      (S3 :accessor C2-S3)))

Instances of the class C1 have a local slot named S1, whose default initial value is 5.4 and whose value should always be a number. The class C1 also has a shared slot named S2.

There is a local slot named S1 in instances of C2. The default initial value of S1 is 5. The value of S1 should always be of type (and integer number). There are also local slots named S2 and S3 in instances of C2. The class C2 has a method for C2-S3 for reading the value of slot S3; there is also a method for (setf C2-S3) that writes the value of S3.

4.3.5.2 Inheritance of Class Options#

If a given :default-initargs class option specifies an initialization argument of the same name more than once, an error of type program-error is signaled.

4.3.6 Determining the Class Precedence List#

The defclass form for a class provides a total ordering on that class and its direct superclasses. This ordering is called the local precedence order. It is an ordered list of the class and its direct superclasses. The class precedence list for a class $C$ is a total ordering on $C$ and its superclasses that is consistent with the local precedence orders for each of $C$ and its superclasses.

A class precedes its direct superclasses, and a direct superclass precedes all other direct superclasses specified to its right in the superclasses list of the defclass form. For every class $C$, define

Let $S_C$ be the set of $C$ and its superclasses. Let $R$ be

Reviewer: Barmar: “Consistent” needs to be defined, or maybe we should say “logically consistent”?!!! The set $R$ might or might not generate a partial ordering, depending on whether the $R_c$, $c\in S_C$, are consistent; it is assumed that they are consistent and that $R$ generates a partial ordering. When the $R_c$ are not consistent, it is said that $R$ is inconsistent.

This partial ordering is generated by taking the the transitive closure of the set $R\cup \{(c,c) \vert c\in {S\sub C}\}$. When $(C\sub 1,C\sub 2)\in R$\negthinspace, it is said that $C\sub 1$ or equals $C\sub 2$ when $C\sub 1=C\sub 2$ or $C\sub 2$ is a superclass of $C\sub 1$. Recall that a partial ordering of the set $S$ is a relation between objects of $S$ that is transitive, reflexive, and antisymmetric. The set $\{(c,c) \vert c\in {S\subC}\}$ was added to the transitive closure of the set $R$ in order to make the relation reflexive. In the remainder of this section the set of precedence relations $R$ and not the partial ordering will be used.

To compute the class precedence list for $C$, topologically sort the elements of $S_C$ with respect to the partial ordering generated by $R$. When the topological sort must select a class from a set of two or more classes, none of which are preceded by other classes with respect to $R$, the class selected is chosen deterministically, as described below.

If $R$ is inconsistent, an error is signaled.

4.3.6.1 Topological Sorting#

If $S_C$ is not empty and the process has stopped, the set $R$ is inconsistent. If every class in the finite set of classes is preceded by another, then $R$ contains a loop. That is, there is a chain of classes $C_1,\dots ,C_n$ such that $C_i$ precedes $C_{i+1}$, $1\le i<n$, and $C_n$ precedes $C_1$.

Sometimes there are several classes from $S_C$ with no predecessors. In this case select the one that has a direct subclass rightmost in the class precedence list computed so far. Because a direct superclass precedes all other direct superclasses to its right, there can be only one such candidate class. Barmar thinks the next sentence is redundant with previous paragraph, but I think it's useful for emphasis. I put it in parens to deemphasize it. -kmp 11-Oct-90(If there is no such candidate class, $R$ does not generate a partial ordering—the $R_c$, $c\in S_C$, are inconsistent.)

In more precise terms, let $\{N_1,\dots ,N_m\}$, $m\ge 2$, be the classes from $S_C$ with no predecessors. Let $(C_1\dots C_n)$, $n\ge 1$, be the class precedence list constructed so far. $C_1$ is the most specific class, and $C_n$ is the least specific. Let $1\le j\le n$ be the largest number such that there exists an $i$ where $1\le i\le m$ and $N_i$ is a direct superclass of $C_j$; $N_i$ is placed next.

The effect of this rule for selecting from a set of \term{classes} with no predecessors is that the \term{classes} in a simple \term{superclass} chain are adjacent in the \term{class precedence list} and that \term{classes} in each relatively separated subgraph are adjacent in the \term{class precedence list}. For example, let $T\sub 1$ and $T\sub 2$ be subgraphs whose only element in common is the class $J$\negthinspace. Suppose that no \term{superclass} of $J$ appears in either $T\sub 1$ or $T\sub 2$. Let $C\sub 1$ be the bottom of $T\sub 1$; and let $C\sub 2$ be the bottom of $T\sub 2$. Suppose $C$ is a \term{class} whose direct \term{superclasses} are $C\sub 1$ and $C\sub 2$ in that order, then the \term{class precedence list} for $C$ will start with $C$ and will be followed by all \term{classes} in $T\sub 1$ except $J$. All the \term{classes} of $T\sub 2$ will be next. The class $J$ and its \term{superclasses} will appear last. Replaced as follows per RPG. -kmp 13-Jan-92

The effect of this rule for selecting from a set of classes with no predecessors is that the classes in a simple superclass chain are adjacent in the class precedence list and that classes in each relatively separated subgraph are adjacent in the class precedence list. For example, let $T_1$ and $T_2$ be subgraphs whose only element in common is the class $J$. Suppose that no \term{superclass} of $J$ appears in either $T\sub 1$ or $T\sub 2$ and that $J$ is an indirect superclass of every class in both $T\sub 1$ and $T\sub 2$. Rewritten by RPG to avoid use of "indirect superclass". -kmp 13-Jan-92Suppose that no superclass of $J$ appears in either $T_1$ or $T_2$, and that $J$ is in the superclass chain of every class in both $T_1$ and $T_2$. Let $C_1$ be the bottom of $T_1$; and let $C_2$ be the bottom of $T_2$. Suppose $C$ is a class whose direct superclasses are $C_1$ and $C_2$ in that order, then the class precedence list for $C$ starts with $C$ and is followed by all classes in $T_1$ except $J$. All the classes of $T_2$ are next. The class $J$ and its superclasses appear last.

4.3.6.2 Examples of Class Precedence List Determination#

 (defclass pie (apple cinnamon) ())
 
 (defclass apple (fruit) ())
 
 (defclass cinnamon (spice) ())
 
 (defclass fruit (food) ())

 (defclass spice (food) ())

 (defclass food () ())

$S$ => "$S\sub{pie}$ per Barmar and Laubsch.The set $S_{\mathrm{pie}}$ $=$ $\{$ pie, apple, cinnamon, fruit, spice, food, standard-object, t$\}$. The set $R$ $=$ $\{$ (pie, apple), (apple, cinnamon), (apple, fruit), (cinnamon, spice), (fruit, food), (spice, food), (food, standard-object), (standard-object, t)$\}$.

The class pie is not preceded by anything, so it comes first; the result so far is (pie). Remove pie from $S$ and pairs mentioning pie from $R$ to get $S$ $=$ $\{$ apple, cinnamon, fruit, spice, food, standard-object, t$\}$ and $R$ $=$ $\{$ (apple, cinnamon), (apple, fruit), (cinnamon, spice), (fruit, food), (spice, food), (food, standard-object), (standard-object, t)$\}$.

The class apple is not preceded by anything, so it is next; the result is (pie apple). Removing apple and the relevant pairs results in $S$ $=$ $\{$ cinnamon, fruit, spice, food, standard-object, t$\}$ and $R$ $=$ $\{$ (cinnamon, spice), (fruit, food), (spice, food), (food, standard-object), (standard-object, t)$\}$.

The classes cinnamon and fruit are not preceded by anything, so the one with a direct subclass rightmost in the class precedence list computed so far goes next. The class apple is a direct subclass of fruit, and the class pie is a direct subclass of cinnamon. Because apple appears to the right of pie in the class precedence list, fruit goes next, and the result so far is (pie apple fruit). $S$ $=$ $\{$ cinnamon, spice, food, standard-object, t$\}$; $R$ $=$ $\{$ (cinnamon, spice), (spice, food), (food, standard-object), (standard-object, t)$\}$.

The class cinnamon is next, giving the result so far as (pie apple fruit cinnamon). At this point $S$ $=$ $\{$ spice, food, standard-object, t$\}$; $R$ $=$ $\{$ (spice, food), (food, standard-object), (standard-object, t)$\}$.

The classes spice, food, standard-object, and t are added in that order, and the class precedence list is (pie apple fruit cinnamon spice food standard-object t).

It is possible to write a set of class definitions that cannot be ordered. For example:

 (defclass new-class (fruit apple) ())
 
 (defclass apple (fruit) ())

The class fruit must precede apple because the local ordering of superclasses must be preserved. The class apple must precede fruit because a class always precedes its own superclasses. When this situation occurs, an error is signaled, as happens here when the system tries to compute the class precedence list Barmar suggested we add:of new-class.

The following might appear to be a conflicting set of definitions:

 (defclass pie (apple cinnamon) ())
 
 (defclass pastry (cinnamon apple) ())
 
 (defclass apple () ())
 
 (defclass cinnamon () ())

The class precedence list for pie is (pie apple cinnamon standard-object t).

The class precedence list for pastry is (pastry cinnamon apple standard-object t).

It is not a problem for apple to precede cinnamon in the ordering of the superclasses of pie but not in the ordering for pastry. However, it is not possible to build a new class that has both pie and pastry as superclasses.

4.3.7 Redefining Classes#

"instance" => "direct instance" per Barrett,Barmar,Moon.A class that is a direct instance of standard-class can be redefined if the new class is also "instance" => "direct instance" per Barrett,Barmar,Moon.a direct instance of standard-class. Redefining a class modifies the existing class object to reflect the new class definition; it does not create a new class object for the class. Any method object created by a :reader, :writer, or :accessor option specified by the old defclass form is removed from the corresponding generic function. Methods specified by the new defclass form are added.

any function specified by the \kwd{constructor} option of the old \macref{defclass} form is removed from the corresponding symbol function cell.

When the class $C$ is redefined, changes are propagated to its instances and to instances of any of its subclasses. Updating such an instance occurs at an implementation-dependent time, but no later than the next time a slot of that instance is read or written. Updating an instance does not change its identity as defined by the function eq. The updating process may change the slots of that particular instance, but it does not create a new instance. Whether updating an instance consumes storage is implementation-dependent.

Note that redefining a class may cause slots to be added or deleted. If a class is redefined in a way that changes the set of local slots accessible in instances, the instances are updated. It is implementation-dependent whether instances are updated if a class is redefined in a way that does not change the set of local slots accessible in instances.

The value of a slot that is specified as shared both in the old class and in the new class is retained. If such a shared slot was unbound in the old class, it is unbound in the new class. Slots that were local in the old class and that are shared in the new class are initialized. Newly added shared slots are initialized.

Each newly added shared slot is set to the result of evaluating the captured \kwd{initform} formcaptured initialization form for the slot that was specified in the defclass form for the new class. If there is no \kwd{initform} form,If there was no initialization form, the slot is unbound.

If a class is redefined in such a way that the set of local slots accessible in an instance of the class is changed, a two-step process of updating the instances of the class takes place. The process may be explicitly started by invoking the generic function make-instances-obsolete. This two-step process can happen in other circumstances in some implementations. For example, in some implementations this two-step process is triggered if the order of slots in storage is changed.

The first step modifies the structure of the instance by adding new local slots and discarding local slots that are not defined in the new version of the class. The second step initializes the newly-added local slots and performs any other user-defined actions. These two steps are further specified in the next two sections.

4.3.7.1 Modifying the Structure of Instances#

The values of local slots specified by both the new and old classes are retained. If such a local slot was unbound, it remains unbound.

The value of a slot that is specified as shared in the old class and as local in the new class is retained. If such a shared slot was unbound, the local slot is unbound.

4.3.7.2 Initializing Newly Added Local Slots#

The generic function update-instance-for-redefined-class takes four required arguments: the instance being updated after it has undergone the first step, a list of the names of local slots that were added, a list of the names of local slots that were discarded, and a property list containing the slot names and values of slots that were discarded and had values. Included among the discarded slots are slots that were local in the old class and that are shared in the new class.

The generic function update-instance-for-redefined-class also takes any number of initialization arguments. When it is called by the system to update an instance whose class has been redefined, no initialization arguments are provided.

There is a system-supplied primary method for update-instance-for-redefined-class whose parameter specializer for its instance argument is the class standard-object. First this method checks the validity of initialization arguments and signals an error if an initialization argument is supplied that is not declared as valid. (For more information, see Section 7.1.2 (Declaring the Validity of Initialization Arguments).) Then it calls the generic function shared-initialize with the following arguments: the instance, the list of names of the newly added slots, and the initialization arguments it received.

4.3.7.3 Customizing Class Redefinition#

Methods for shared-initialize may be defined to customize class redefinition. For more information, see Section 7.1.5 (Shared-Initialize).

The following was removed by request of Symbolics, who point out that other extensions may well be permitted too, and there's no reason to give special advertising to these. -kmp 9-Oct-90 \beginsubsubsection{Extensions} There are two allowed extensions to \term{class} redefinition: \beginlist \itemitem{\bull} The \OS\ may be extended to permit the new \term{class} to be an \term{instance} of a \term{metaclass} other than the \term{metaclass} of the old \term{class}. \itemitem{\bull} The \OS\ may be extended to support an updating process when either the old or the new \term{class} is an \term{instance} of a \term{class} other than \typeref{standard-class} that is not a \term{built-in class}. \endlist \endsubsubsection%{Extensions}

4.3.8 Integrating Types and Classes#

The object system maps the space of classes into the space of types. Every class that has a proper name has a corresponding type with the same name.

The proper name of every class is a valid type specifier. In addition, every class object is a valid type specifier. Thus the expression (typep object class) evaluates to true if the class of object is class itself or a subclass of class. The evaluation of the expression (subtypep class1 class2) returns the values was {\tt t~t} but came out as "t~t" in formatted form. -kmp 10-Oct-90 \t~\t\ if \f{class1} is a subclass of \f{class2} or if they are thetrue and true if class1 is a subclass of class2 or if they are the same class; otherwise it returns the values was {\tt nil~t} \nil~\t.false and true. If $I$ is an \term{instance} of some \term{class} $C$ named $S$ and $C$ is an \term{instance} of \typeref{standard-class}, the evaluation of the expression \f{(type-of $I$\/)} will return $S$ if $S$ is the proper name of $C$\negthinspace; if $S$ is not the proper name of $C$\negthinspace, the expression \f{(type-of $I$\/)} will return $C$\negthinspace. Barmar thought the above was too complicated. This is a partial simplification, not quite what he wanted, but hopefully an improvement.If $I$ is an instance of some class $C$ named $S$ and $C$ is an instance of standard-class, the evaluation of the expression (type-of $I$) returns $S$ if $S$ is the proper name of $C$; otherwise, it returns $C$.

Because the names of classes and class objects are type specifiers, they may be used in the special form the and in type declarations.

Many but not all of the predefined type specifiers have a corresponding class with the same proper name as the type. These type specifiers are listed in Figure 4–8. For example, the type array has a corresponding class named array. No type specifier that is a list, such as (vector double-float 100), has a corresponding class. The operator deftype does not create any classes.

Each class that corresponds to a predefined type specifier can be implemented in one of three ways, at the discretion of each implementation. It can be a standard class, Not necessary. -kmp 12-Feb-92 (of the kind defined by \macref{defclass}),a structure class, Not necessary. -kmp 12-Feb-92 (defined by \macref{defstruct}), or a \term{built-in class}.or a system class. Not necessary. -kmp 12-Feb-92 (implemented in a special, non-extensible way).

"instances" => "generalized instances" per Barmar,Moon.A built-in class is one whose generalized instances have restricted capabilities or special representations. Attempting to use defclass to define subclasses of a built-in-class signals an error. "instance" => "generalized instance" per Barmar,Moon.Calling make-instance to create a generalized instance of a built-in class signals an error. Calling slot-value on a "instance" => "generalized instance" per Barmar,Moon.generalized instance of a built-in class signals an error. Redefining a built-in class or using change-class to change "instance" => "object" per Barmar,Moon.the class of an object to or from a built-in class signals an error. However, built-in classes can be used as parameter specializers in methods.

The \OS\ specifies that all predefined \term{type specifiers} listed in \figref\ClassTypeCorrespondence\ are built-in classes, but a particular implementation is allowed to extend the \OS\ to define some of them as standard classes or as structure classes.

It is possible to determine whether a class is a built-in class by checking the metaclass. A standard class is an instance of the class standard-class, a built-in class is an instance of the class built-in-class, and a structure class is an instance of the class structure-class.

Each structure type created by defstruct without using the :type option has a corresponding class. "instance" => "generalized instance" per Barmar,Moon.This class is a generalized instance of the class structure-class. A portable program must assume that \typeref{structure-class} is a subclass of \typeref{built-in-class} and has the same restrictions as built-in classes. Whether \theclass{structure-class} in fact is a subclass of \typeref{built-in-class} is \term{implementation-dependent}.The :include option of defstruct creates a direct subclass of the class that corresponds to the included structure Added "type" -kmptype.

I moved the following two paragraphs here from the dictionary entry for CLASS. --sjl 7 Mar 92 It is implementation-dependent whether slots are involved in the operation of functions defined in this specification on instances of classes defined in this specification, except when slots are explicitly defined by this specification.

If in a particular implementation a class defined in this specification has slots that are not defined by this specfication, the names of these slots must not be external symbols of packages defined in this specification nor otherwise accessible in the cl-user package.

The purpose of specifying that many of the standard type specifiers have a corresponding class is to enable users to write methods that discriminate on these types. Method selection requires that a class precedence list can be determined for each class.

The hierarchical relationships among the type specifiers are mirrored by relationships among the classes corresponding to those types. The existing type hierarchy is used for determining the \term{class precedence list} for each \term{class} that corresponds to a predefined \term{type}. In some cases, a \term{local precedence order} is not specifiied for two \term{supertypes} of a given \term{type specifier}. For example, \typeref{null} is a \term{subtype} of both \typeref{symbol} and \typeref{list}, but it is not specified whether \typeref{symbol} is more specific or less specific than \typeref{list}. The \CLOS\ defines those relationships for all such \term{classes}.

Figure 4–8 lists the set of classes that correspond to predefined type specifiers.

The class precedence list information specified in the entries for each of these classes are those that are required by the object system.

Individual implementations may be extended to define other type specifiers to have a corresponding class. Individual implementations may be extended to add other subclass relationships and to add other elements to the class precedence lists as long as they do not violate the type relationships and disjointness requirements specified by this standard. A standard class defined with no direct superclasses is guaranteed to be disjoint from all of the classes in the table, except for the class named t.

Dictionary

• nil Type
• boolean Type
• function System Class
• compiled-function Type
• generic-function System Class
• standard-generic-function System Class
• class System Class
• built-in-class System Class
• structure-class System Class
• standard-class System Class
• method System Class
• standard-method System Class
• structure-object Class
• standard-object Class
• method-combination System Class
• t System Class
• satisfies Type Specifier
• member Type Specifier
• not Type Specifier
• and Type Specifier
• or Type Specifier
• values Type Specifier
• eql Type Specifier
• coerce Function
• deftype Macro
• subtypep Function
• type-of Function
• typep Function
• type-error Condition Type
• type-error-datum, type-error-expected-type Function
• simple-type-error Condition Type