Is this the last holdout of the CAPITAL symbol names?
(:documentation
"Classes describe the layout and behaviour of objects.
(:documentation
"Classes describe the layout and behaviour of objects.
- The NAME, LOCATION, NICKNAME, DIRECT-SUPERCLASSES, CHAIN-LINK and
- METACLASS slots are intended to be initialized when the class object is
- constructed:
+ The `name', `location', `nickname', `direct-superclasses', `chain-link'
+ and `metaclass' slots are intended to be initialized when the class object
+ is constructed:
- * The NAME is the identifier associated with the class in the user's
+ * The `name' is the identifier associated with the class in the user's
source file. It is used verbatim in the generated C code as a type
name, and must be distinct from other file-scope names in any source
file which includes the class definition. Furthermore, other names
are derived from the class name (most notably the class object
NAME__class), which have external linkage and must therefore be
distinct from all other identifiers in the program. It is forbidden
source file. It is used verbatim in the generated C code as a type
name, and must be distinct from other file-scope names in any source
file which includes the class definition. Furthermore, other names
are derived from the class name (most notably the class object
NAME__class), which have external linkage and must therefore be
distinct from all other identifiers in the program. It is forbidden
- for a class NAME to begin with an underscore or to contain two
+ for a class `name' to begin with an underscore or to contain two
- * The LOCATION identifies where in the source the class was defined. It
- gets used in error messages.
+ * The `location' identifies where in the source the class was defined.
+ It gets used in error messages.
- * The NICKNAME is a shorter identifier used to name the class in some
- circumstances. The uniqueness requirements on NICKNAME are less
+ * The `nickname' is a shorter identifier used to name the class in some
+ circumstances. The uniqueness requirements on `nickname' are less
strict, which allows them to be shorter: no class may have two classes
with the same nickname on its class precedence list. Nicknames are
used (user-visibly) to distinguish slots and messages defined by
strict, which allows them to be shorter: no class may have two classes
with the same nickname on its class precedence list. Nicknames are
used (user-visibly) to distinguish slots and messages defined by
methods. It is forbidden for a nickname to begin with an underscore,
or to contain two consecutive underscores.
methods. It is forbidden for a nickname to begin with an underscore,
or to contain two consecutive underscores.
- * The DIRECT-SUPERCLASSES are a list of the class's direct superclasses,
- in the order that they were declared in the source. The class
- precedence list is computed from the DIRECT-SUPERCLASSES lists of all
- of the superclasses involved.
+ * The `direct-superclasses' are a list of the class's direct
+ superclasses, in the order that they were declared in the source. The
+ class precedence list is computed from the `direct-superclasses' lists
+ of all of the superclasses involved.
- * The CHAIN-LINK is either NIL or one of the DIRECT-SUPERCLASSES. Class
- chains are a means for recovering most of the benefits of simple
+ * The `chain-link' is either `nil' or one of the `direct-superclasses'.
+ Class chains are a means for recovering most of the benefits of simple
hierarchy lost by the introduction of multiple inheritance. A class's
superclasses (including itself) are partitioned into chains,
hierarchy lost by the introduction of multiple inheritance. A class's
superclasses (including itself) are partitioned into chains,
- consisting of a class, its CHAIN-LINK superclass, that class's
- CHAIN-LINK, and so on. It is an error if two direct subclasses of any
- class appear in the same chain (a global property which requires
+ consisting of a class, its `chain-link' superclass, that class's
+ `chain-link', and so on. It is an error if two direct subclasses of
+ any class appear in the same chain (a global property which requires
global knowledge of an entire program's class hierarchy in order to
determine sensibly). Slots of superclasses in the same chain can be
accessed efficiently; there is an indirection needed to access slots
global knowledge of an entire program's class hierarchy in order to
determine sensibly). Slots of superclasses in the same chain can be
accessed efficiently; there is an indirection needed to access slots
occurs implicitly in effective methods in order to call direct methods
defined on cross-chain superclasses.
occurs implicitly in effective methods in order to call direct methods
defined on cross-chain superclasses.
- * The METACLASS is the class of the class object. Classes are objects
+ * The `metaclass' is the class of the class object. Classes are objects
in their own right, and therefore must be instances of some class;
this class is the metaclass. Metaclasses can define additional slots
and methods to be provided by their instances; a class definition can
in their own right, and therefore must be instances of some class;
this class is the metaclass. Metaclasses can define additional slots
and methods to be provided by their instances; a class definition can
The next few slots can't usually be set at object-construction time, since
the objects need to contain references to the class object itself.
The next few slots can't usually be set at object-construction time, since
the objects need to contain references to the class object itself.
- * The SLOTS are a list of the slots defined by the class (instances of
+ * The `slots' are a list of the slots defined by the class (instances of
`sod-slot'). (The class will also define all of the slots defined by
its superclasses.)
`sod-slot'). (The class will also define all of the slots defined by
its superclasses.)
- * The INSTANCE-INITIALIZERS and CLASS-INITIALIZERS are lists of
+ * The `instance-initializers' and `class-initializers' are lists of
initializers for slots (see `sod-initializer' and subclasses),
providing initial values for instances of the class, and for the
class's class object itself, respectively.
initializers for slots (see `sod-initializer' and subclasses),
providing initial values for instances of the class, and for the
class's class object itself, respectively.
- * The MESSAGES are a list of the messages recognized by the class
+ * The `messages' are a list of the messages recognized by the class
(instances of `sod-message' and subclasses). (Note that the message
need not have any methods defined on it. The class will also
recognize all of the messages defined by its superclasses.)
(instances of `sod-message' and subclasses). (Note that the message
need not have any methods defined on it. The class will also
recognize all of the messages defined by its superclasses.)
- * The METHODS are a list of (direct) methods defined on the class
+ * The `methods' are a list of (direct) methods defined on the class
(instances of `sod-method' and subclasses). Each method provides
behaviour to be invoked by a particular message recognized by the
class.
(instances of `sod-method' and subclasses). Each method provides
behaviour to be invoked by a particular message recognized by the
class.
Other slots are computed from these in order to describe the class's
layout and effective methods; this is done by `finalize-sod-class'.
Other slots are computed from these in order to describe the class's
layout and effective methods; this is done by `finalize-sod-class'.
- * The CLASS-PRECEDENCE-LIST is a list of superclasses in a linear order.
- It is computed by `compute-class-precedence-list', whose default
- implementation ensures that the order of superclasses is such that (a)
- subclasses appear before their superclasses; (b) the direct
+ * The `class-precedence-list' is a list of superclasses in a linear
+ order. It is computed by `compute-class-precedence-list', whose
+ default implementation ensures that the order of superclasses is such
+ that (a) subclasses appear before their superclasses; (b) the direct
superclasses of a given class appear in the order in which they were
declared by the programmer; and (c) classes always appear in the same
relative order in all class precedence lists in the same superclass
graph.
superclasses of a given class appear in the order in which they were
declared by the programmer; and (c) classes always appear in the same
relative order in all class precedence lists in the same superclass
graph.
- * The CHAIN-HEAD is the least-specific class in the class's chain. If
- there is no link class then the CHAIN-HEAD is the class itself. This
- slot, like the next two, is computed by the generic function
+ * The `chain-head' is the least-specific class in the class's chain. If
+ there is no link class then the `chain-head' is the class itself.
+ This slot, like the next two, is computed by the generic function
- * The CHAIN is the list of classes on the complete primary chain,
- starting from this class and ending with the CHAIN-HEAD.
+ * The `chain' is the list of classes on the complete primary chain,
+ starting from this class and ending with the `chain-head'.
- * The CHAINS are the complete collection of chains (most-to-least
+ * The `chains' are the complete collection of chains (most-to-least
specific) for the class and all of its superclasses.
Finally, slots concerning the instance and vtable layout of the class are
computed on demand (see `define-on-demand-slot').
specific) for the class and all of its superclasses.
Finally, slots concerning the instance and vtable layout of the class are
computed on demand (see `define-on-demand-slot').
- * The ILAYOUT describes the layout for an instance of the class. It's
+ * The `ilayout' describes the layout for an instance of the class. It's
quite complicated; see the documentation of the `ilayout' class for
detais.
quite complicated; see the documentation of the `ilayout' class for
detais.
- * The EFFECTIVE-METHODS are a list of effective methods, specialized for
- the class.
+ * The `effective-methods' are a list of effective methods, specialized
+ for the class.
- * The VTABLES are a list of descriptions of vtables for the class. The
- individual elements are `vtable' objects, which are even more
+ * The `vtables' are a list of descriptions of vtables for the class.
+ The individual elements are `vtable' objects, which are even more
complicated than `ilayout' structures. See the class documentation
for details."))
complicated than `ilayout' structures. See the class documentation
for details."))
A slot carries the following information.
A slot carries the following information.
- * A NAME, which distinguishes it from other slots defined by the same
+ * A `name', which distinguishes it from other slots defined by the same
class. Unlike most (all?) other object systems, slots defined in
different classes are in distinct namespaces. There are no special
restrictions on slot names.
class. Unlike most (all?) other object systems, slots defined in
different classes are in distinct namespaces. There are no special
restrictions on slot names.
- * A LOCATION, which states where in the user's source the slot was
+ * A `location', which states where in the user's source the slot was
defined. This gets used in error messages.
defined. This gets used in error messages.
- * A CLASS, which states which class defined the slot. The slot is
+ * A `class', which states which class defined the slot. The slot is
available in instances of this class and all of its descendents.
available in instances of this class and all of its descendents.
- * A TYPE, which is the C type of the slot. This must be an object type
- (certainly not a function type, and it must be a complete type by the
- time that the user header code has been scanned)."))
+ * A `type', which is the C type of the slot. This must be an object
+ type (certainly not a function type, and it must be a complete type by
+ the time that the user header code has been scanned)."))
(defmethod print-object ((slot sod-slot) stream)
(maybe-print-unreadable-object (slot stream :type t)
(defmethod print-object ((slot sod-slot) stream)
(maybe-print-unreadable-object (slot stream :type t)
The slots of an initializer are as follows.
The slots of an initializer are as follows.
- * The SLOT specifies which slot this initializer is meant to initialize.
+ * The `slot' specifies which slot this initializer is meant to
+ initialize.
- * The LOCATION states the position in the user's source file where the
+ * The `location' states the position in the user's source file where the
initializer was found. This gets used in error messages. (Depending
on the source layout style, this might differ from the location in the
initializer was found. This gets used in error messages. (Depending
on the source layout style, this might differ from the location in the
- * The CLASS states which class defined this initializer. For instance
+ * The `class' states which class defined this initializer. For instance
slot initializers (`sod-instance-initializer'), this will be the same
slot initializers (`sod-instance-initializer'), this will be the same
- as the SLOT's class, or be one of its descendants. For class slot
+ as the `slot''s class, or be one of its descendants. For class slot
initializers (`sod-class-initializer'), this will be an instance of
initializers (`sod-class-initializer'), this will be an instance of
- the SLOT's class, or an instance of one of its descendants.
+ the `slot''s class, or an instance of one of its descendants.
- * The VALUE gives the text of the initializer, as a C fragment.
+ * The `value' gives the text of the initializer, as a C fragment.
Typically you'll see instances of subclasses of this class in the wild
rather than instances of this class directly. See `sod-class-initializer'
Typically you'll see instances of subclasses of this class in the wild
rather than instances of this class directly. See `sod-class-initializer'
"Provides an initial value for a slot in all instances.
An instance slot initializer provides an initial value for a slot in
"Provides an initial value for a slot in all instances.
An instance slot initializer provides an initial value for a slot in
- instances of the class. Its VALUE must have the syntax of an initializer.
- Furthermore, if the slot has aggregate type, then you'd better be sure
- that your compiler supports compound literals (6.5.2.5) because that's
- what the initializer gets turned into.
+ instances of the class. Its `value' must have the syntax of an
+ initializer. Furthermore, if the slot has aggregate type, then you'd
+ better be sure that your compiler supports compound literals (6.5.2.5)
+ because that's what the initializer gets turned into.
See `sod-initializer' for more details."))
See `sod-initializer' for more details."))
The slots are as follows.
The slots are as follows.
- * The NAME distinguishes the message from others defined by the same
+ * The `name' distinguishes the message from others defined by the same
class. Unlike most (all?) other object systems, messages defined in
different classes are in distinct namespaces. It is forbidden for a
message name to begin with an underscore, or to contain two
consecutive underscores. (Final underscores are fine.)
class. Unlike most (all?) other object systems, messages defined in
different classes are in distinct namespaces. It is forbidden for a
message name to begin with an underscore, or to contain two
consecutive underscores. (Final underscores are fine.)
- * The LOCATION states where in the user's source the slot was defined.
+ * The `location' states where in the user's source the slot was defined.
It gets used in error messages.
It gets used in error messages.
- * The CLASS states which class defined the message.
+ * The `class' states which class defined the message.
- * The TYPE is a function type describing the message's arguments and
+ * The `type' is a function type describing the message's arguments and
return type.
Subclasses can (and probably will) define additional slots."))
return type.
Subclasses can (and probably will) define additional slots."))
The slots are as follows.
The slots are as follows.
- * The MESSAGE describes which meessage invokes the method's behaviour.
+ * The `message' describes which meessage invokes the method's behaviour.
The method is combined with other methods on the same message
according to the message's method combination, to form an `effective
method'.
The method is combined with other methods on the same message
according to the message's method combination, to form an `effective
method'.
- * The LOCATION states where, in the user's source, the method was
+ * The `location' states where, in the user's source, the method was
defined. This gets used in error messages. (Depending on the user's
defined. This gets used in error messages. (Depending on the user's
- coding style, this location might be subtly different from the BODY's
- location.)
+ coding style, this location might be subtly different from the
+ `body''s location.)
- * The CLASS specifies which class defined the method. This will be
+ * The `class' specifies which class defined the method. This will be
either the class of the message, or one of its descendents.
either the class of the message, or one of its descendents.
- * The TYPE gives the type of the method, including its arguments. This
- will, in general, differ from the type of the message for several
+ * The `type' gives the type of the method, including its arguments.
+ This will, in general, differ from the type of the message for several
reasons.
-- The method type must include names for all of the method's
reasons.
-- The method type must include names for all of the method's
~mdw / sod / commitdiff