2797 lines
130 KiB
HTML
2797 lines
130 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
|
|
<!Converted with LaTeX2HTML 0.6.5 (Tue Nov 15 1994) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds >
|
|
<HEAD>
|
|
<TITLE>28.2. Functions in the Programmer Interface</TITLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<meta name="description" value=" Functions in the Programmer Interface">
|
|
<meta name="keywords" value="clm">
|
|
<meta name="resource-type" value="document">
|
|
<meta name="distribution" value="global">
|
|
<P>
|
|
<b>Common Lisp the Language, 2nd Edition</b>
|
|
<BR> <HR><A NAME=tex2html5535 HREF="node312.html"><IMG ALIGN=BOTTOM ALT="next" SRC="icons/next_motif.gif"></A> <A NAME=tex2html5533 HREF="node260.html"><IMG ALIGN=BOTTOM ALT="up" SRC="icons/up_motif.gif"></A> <A NAME=tex2html5529 HREF="node310.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="icons/previous_motif.gif"></A> <A NAME=tex2html5537 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="icons/contents_motif.gif"></A> <A NAME=tex2html5538 HREF="index.html"><IMG ALIGN=BOTTOM ALT="index" SRC="icons/index_motif.gif"></A> <BR>
|
|
<B> Next:</B> <A NAME=tex2html5536 HREF="node312.html"> Conditions</A>
|
|
<B>Up:</B> <A NAME=tex2html5534 HREF="node260.html"> Common Lisp Object </A>
|
|
<B> Previous:</B> <A NAME=tex2html5530 HREF="node310.html"> Customizing Reinitialization</A>
|
|
<HR> <P>
|
|
<H1><A NAME=SECTION003220000000000000000>28.2. Functions in the Programmer Interface</A></H1>
|
|
<P>
|
|
<img align=bottom alt="change_begin" src="gif/change_begin.gif"><br>
|
|
<A NAME=FunctionsintheProgrammerInterfaceSECTION>This</A>
|
|
section describes the functions, macros, special forms, and
|
|
generic functions provided by the Common Lisp Object System Programmer Interface. The
|
|
Programmer Interface comprises the functions and macros that are
|
|
sufficient for writing most object-oriented programs.
|
|
<P>
|
|
This section is reference material that requires an understanding of
|
|
the basic concepts of the Common Lisp Object System. The functions
|
|
are arranged in alphabetical order for convenient reference.
|
|
<P>
|
|
The description of each function, macro, special form,
|
|
and generic function includes its purpose, its syntax, the
|
|
semantics of its arguments and returned values, and often an example
|
|
and cross-references to related functions.
|
|
<P>
|
|
The syntax description for a function, macro, or special form
|
|
describes its parameters.
|
|
The description of a generic function includes descriptions of the
|
|
methods that are defined on that generic function by the Common Lisp Object System. A
|
|
<i>method signature</i> is used to describe the parameters and
|
|
parameter specializers for each method.
|
|
<P>
|
|
The following is an example of the format for
|
|
the syntax description of a generic function with the method
|
|
signature for one primary method:
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>f <i>x</i> <i>y</i> &optional <i>z</i> &key :k</tt>
|
|
<br><b>[Primary method]</b><br>
|
|
<tt>f (<i>x</i> <i>class</i>) (<i>y</i> <i>t</i>) &optional <i>z</i> &key :k</tt><P>This description indicates that the generic function <tt>f</tt>
|
|
has two required parameters, <i>x</i> and <i>y</i>. In addition,
|
|
there is an optional parameter <i>z</i> and a keyword parameter <tt>:k</tt>.
|
|
<P>
|
|
The method signature indicates that this method on the generic function
|
|
<tt>f</tt> has two required parameters, <i>x</i>, which must be an
|
|
instance of the class <tt>class</tt>, and <i>y</i>, which can be any
|
|
object. In addition, there is an optional parameter <i>z</i> and a
|
|
keyword parameter <tt>:k</tt>. The signature also indicates that this
|
|
method on <tt>f</tt> is a primary method and has no qualifiers.
|
|
<P>
|
|
The syntax description for a generic function describes the
|
|
lambda-list of the generic function itself, while the method
|
|
signatures describe the lambda-lists of the defined methods.
|
|
<P>
|
|
The generic functions described in this book are all standard
|
|
generic functions. They all use standard method combination.
|
|
<P>
|
|
Any implementation of the Common Lisp Object System is allowed to provide additional methods
|
|
on the generic functions described here.
|
|
<P>
|
|
It is useful to categorize the functions and macros according to their
|
|
role in this standard:
|
|
|
|
<P>
|
|
<UL><LI>
|
|
<i>Tools used for simple object-oriented programming</i>
|
|
<P>
|
|
These tools allow for defining new classes, methods, and generic
|
|
functions and for making instances. Some tools used within
|
|
method bodies are also listed here. Some of the macros listed here have
|
|
a corresponding function that performs the same task at a lower level of
|
|
abstraction.
|
|
<P>
|
|
<listing>
|
|
call-next-method initialize-instance
|
|
change-class make-instance
|
|
defclass next-method-p
|
|
defgeneric slot-boundp
|
|
defmethod slot-value
|
|
generic-flet with-accessors
|
|
generic-function with-added-methods
|
|
generic-labels with-slots
|
|
</listing>
|
|
<LI>
|
|
<i>Functions underlying the commonly used macros</i>
|
|
<P>
|
|
<listing>
|
|
add-method reinitialize-instance
|
|
class-name remove-method
|
|
compute-applicable-methods shared-initialize
|
|
ensure-generic-function slot-exists-p
|
|
find-class slot-makunbound
|
|
find-method slot-missing
|
|
function-keywords slot-unbound
|
|
make-instances-obsolete update-instance-for-different-class
|
|
no-applicable-method update-instance-for-redefined-class
|
|
no-next-method
|
|
</listing>
|
|
<LI>
|
|
<i>Tools for declarative method combination</i>
|
|
<P>
|
|
<listing>
|
|
call-method method-combination-error
|
|
define-method-combination method-qualifiers
|
|
invalid-method-error
|
|
</listing>
|
|
<LI>
|
|
<i>General Common Lisp support tools</i>
|
|
<P>
|
|
<listing>
|
|
class-of print-object
|
|
documentation symbol-macrolet
|
|
</listing>
|
|
[Note that <tt>describe</tt> appeared in this list in the original CLOS proposal
|
|
[<A HREF="node368.html#SIGPLANCLOS">5</A>,<A HREF="node368.html#LASCCLOSPART2">7</A>], but X3J13 voted in March 1989 (DESCRIBE-UNDERSPECIFIED) <A NAME=33817> </A>
|
|
not to make <tt>describe</tt> a generic function after all (see <tt>describe-object</tt>).-GLS]
|
|
</UL>
|
|
<P>
|
|
[At this point the original CLOS report contained a description of the
|
|
<b>[[</b> and <b>]]</b> notation; that description is omitted here.
|
|
I have adopted the notation for use
|
|
throughout this book. It is described in
|
|
section <A HREF="node12.html#FUNCTIONHEADERNOTATIONSECTION">1.2.5</A>.-GLS]
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>add-method <i>generic-function</i> <i>method</i> </tt>
|
|
<br><b>[Primary method]</b><br>
|
|
<pre>
|
|
add-method
|
|
(<i>generic-function</i> <i>standard-generic-function</i>) (<i>method</i> <i>method</i>)
|
|
</pre>
|
|
<P>The generic function <tt>add-method</tt> adds a method to a generic
|
|
function. It destructively modifies the generic function and returns
|
|
the modified generic function as its result.
|
|
<P>
|
|
The <i>generic-function</i> argument is a generic function
|
|
object.
|
|
<P>
|
|
The <i>method</i> argument is a method object. The lambda-list of
|
|
the method function must be congruent with the lambda-list of the
|
|
generic function, or an error is signaled.
|
|
<P>
|
|
The modified generic function is returned. The result of <tt>add-method</tt>
|
|
is <tt>eq</tt> to the <i>generic-function</i> argument.
|
|
<P>
|
|
If the given method agrees with an existing method of the generic
|
|
function on parameter specializers and qualifiers, the existing method
|
|
is replaced. See section <A HREF="node280.html#AgreementonParameterSpecializersandQualifiersSECTION">28.1.6.3</A>
|
|
for a definition of agreement in this context.
|
|
<P>
|
|
If the method object is a method object of another generic function,
|
|
an error is signaled.
|
|
<P>
|
|
See section <A HREF="node280.html#AgreementonParameterSpecializersandQualifiersSECTION">28.1.6.3</A>
|
|
as well as
|
|
<tt>defmethod</tt>,
|
|
<tt>defgeneric</tt>,
|
|
<tt>find-method</tt>,
|
|
and <tt>remove-method</tt>.
|
|
<P>
|
|
<BR><b>[Macro]</b><BR>
|
|
<tt>call-method <i>method</i> <i>next-method-list</i></tt><P>The macro <tt>call-method</tt> is used in method combination. This macro hides
|
|
the implementation-dependent details of how methods are called. It can be used only within
|
|
an effective method form, for the name <tt>call-method</tt> is defined only
|
|
within the lexical scope of such a form.
|
|
<P>
|
|
The macro <tt>call-method</tt> invokes the specified method, supplying it
|
|
with arguments and with definitions for <tt>call-next-method</tt> and for
|
|
<tt>next-method-p</tt>. The arguments are the arguments that were
|
|
supplied to the effective method form containing the invocation of
|
|
<tt>call-method</tt>. The definitions of <tt>call-next-method</tt> and
|
|
<tt>next-method-p</tt> rely on the list of method objects given as the second
|
|
argument to <tt>call-method</tt>.
|
|
<P>
|
|
The <tt>call-next-method</tt> function available to the method that
|
|
is the first subform will call the first method in the list that
|
|
is the second subform. The <tt>call-next-method</tt> function
|
|
available in that method, in turn, will call the second
|
|
method in the list that is the second subform, and so on, until
|
|
the list of next methods is exhausted.
|
|
<P>
|
|
The <i>method</i> argument is a method object; the <i>next-method-list</i> argument is a list of method objects.
|
|
<P>
|
|
A list whose first element is the symbol <tt>make-method</tt> and whose
|
|
second element is a Lisp form can be used instead of a method object
|
|
as the first subform of <tt>call-method</tt> or as an element of the
|
|
second subform of <tt>call-method</tt>. Such a list specifies a method
|
|
object whose method function has a body that is the given form.
|
|
<P>
|
|
The result of <tt>call-method</tt> is the value or values returned by
|
|
the method invocation.
|
|
<P>
|
|
See <tt>call-next-method</tt>, <tt>define-method-combination</tt>, and <tt>next-method-p</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>call-next-method &rest <i>args</i></tt><P>The function <tt>call-next-method</tt> can be used within the body of a
|
|
method defined by a method-defining form to call the next method.
|
|
<P>
|
|
The function <tt>call-next-method</tt> returns the value or values
|
|
returned by the method it calls. If there is no next method,
|
|
the generic function <tt>no-next-method</tt> is called.
|
|
<P>
|
|
The type of method combination used determines which
|
|
methods can invoke <tt>call-next-method</tt>. The standard method
|
|
combination type allows <tt>call-next-method</tt>
|
|
to be used within primary
|
|
methods and <tt>:around</tt> methods.
|
|
<P>
|
|
The standard method combination
|
|
type defines the next method according to the following rules:
|
|
<P>
|
|
<UL><LI>
|
|
If <tt>call-next-method</tt> is used in an <tt>:around</tt> method,
|
|
the next method is the next most specific <tt>:around</tt> method, if one is
|
|
applicable.
|
|
<P>
|
|
<LI>
|
|
If there are no <tt>:around</tt> methods at all or if
|
|
<tt>call-next-method</tt> is called by the least specific <tt>:around</tt>
|
|
method, other methods are called as follows:
|
|
<P>
|
|
<UL><LI> All the <tt>:before</tt> methods are called, in
|
|
most-specific-first order. The function <tt>call-next-method</tt>
|
|
cannot be used in <tt>:before</tt> methods.
|
|
<P>
|
|
<LI>
|
|
The most specific primary method is called. Inside the body of a
|
|
primary method, <tt>call-next-method</tt> may be used to pass control to
|
|
the next most specific primary method. The generic function
|
|
<tt>no-next-method</tt> is called if <tt>call-next-method</tt> is used and there
|
|
are no more primary methods.
|
|
<P>
|
|
<LI> All the <tt>:after</tt> methods are called in
|
|
most-specific-last order. The function <tt>call-next-method</tt>
|
|
cannot be used in <tt>:after</tt> methods.
|
|
</UL>
|
|
</UL>
|
|
<P>
|
|
For further discussion of the use of <tt>call-next-method</tt>, see
|
|
sections <A HREF="node285.html#StandardMethodCombinationSECTION">28.1.7.2</A>
|
|
and <A HREF="node287.html#BuiltinMethodCombinationTypesSECTION">28.1.7.4</A>.
|
|
<P>
|
|
When <tt>call-next-method</tt> is called with no arguments, it passes the
|
|
current method's original arguments to the next method. Neither
|
|
argument defaulting, nor using <tt>setq</tt>, nor rebinding variables
|
|
with the same names as parameters of the method affects the values
|
|
<tt>call-next-method</tt> passes to the method it calls.
|
|
<P>
|
|
When <tt>call-next-method</tt> is called with arguments, the next method
|
|
is called with those arguments. When providing arguments to
|
|
<tt>call-next-method</tt>, the following rule must be satisfied or an error is
|
|
signaled: The ordered set of methods applicable for a changed set of
|
|
arguments for <tt>call-next-method</tt> must be the same as the ordered set of
|
|
applicable methods for the original arguments to the generic function.
|
|
Optimizations of the error checking are possible, but they must
|
|
not change the semantics of <tt>call-next-method</tt>.
|
|
<P>
|
|
If <tt>call-next-method</tt> is called with arguments but omits
|
|
optional arguments, the next method called defaults those arguments.
|
|
<P>
|
|
The function <tt>call-next-method</tt> returns the value or values
|
|
returned by the method it calls.
|
|
<P>
|
|
Further computation is possible after <tt>call-next-method</tt> returns.
|
|
<P>
|
|
The definition of the function <tt>call-next-method</tt> has lexical scope (for it
|
|
is defined only within the body of a method defined by a method-defining form)
|
|
and indefinite extent.
|
|
<P>
|
|
For generic functions using a type of method combination defined by
|
|
the short form of <tt>define-method-combination</tt>,
|
|
<tt>call-next-method</tt> can be used in <tt>:around</tt> methods only.
|
|
<P>
|
|
The function <tt>next-method-p</tt> can be used to test whether or not there is
|
|
a next method.
|
|
<P>
|
|
If <tt>call-next-method</tt> is used in methods that do not support it,
|
|
an error is signaled.
|
|
<P>
|
|
See sections <A HREF="node283.html#MethodSelectionandCombinationSECTION">28.1.7</A>,
|
|
<A HREF="node285.html#StandardMethodCombinationSECTION">28.1.7.2</A>, and
|
|
<A HREF="node287.html#BuiltinMethodCombinationTypesSECTION">28.1.7.4</A> as well as the functions
|
|
<tt>define-method-combination</tt>,
|
|
<tt>next-method-p</tt>,
|
|
and <tt>no-next-method</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<pre>
|
|
change-class <i>instance</i> <i>new-class</i>
|
|
</pre>
|
|
<br><b>[Primary method]</b><br>
|
|
<pre>
|
|
change-class (<i>instance</i> standard-object)
|
|
(<i>new-class</i> standard-class)
|
|
change-class (<i>instance</i> t)
|
|
(<i>new-class</i> symbol)
|
|
</pre>
|
|
<P>
|
|
The generic function <tt>change-class</tt> changes the class of an
|
|
instance to a new class. It destructively modifies and returns the
|
|
instance.
|
|
<P>
|
|
If in the old class there is any slot of the same name as a local
|
|
slot in the new class, the value of that slot is retained. This
|
|
means that if the slot has a value, the value returned by
|
|
<tt>slot-value</tt> after <tt>change-class</tt> is invoked is <tt>eql</tt> to the
|
|
value returned by <tt>slot-value</tt> before <tt>change-class</tt> is
|
|
invoked. Similarly, if the slot was unbound, it remains
|
|
unbound. The other slots are initialized as described in
|
|
section <A HREF="node305.html#ChangingtheClassofanInstanceSECTION">28.1.11</A>.
|
|
<P>
|
|
The <i>instance</i> argument is a Lisp object.
|
|
<P>
|
|
The <i>new-class</i> argument is a class object or a symbol that names
|
|
a class.
|
|
<P>
|
|
If the second of the preceding methods is selected, that method
|
|
invokes <tt>change-class</tt> on <i>instance</i> and
|
|
<tt>(find-class <i>new-class</i>)</tt>.
|
|
<P>
|
|
The modified instance is returned. The result of <tt>change-class</tt>
|
|
is <tt>eq</tt> to the <i>instance</i> argument.
|
|
<P>
|
|
Examples:
|
|
<P>
|
|
<P><pre>
|
|
(defclass position () ())
|
|
|
|
(defclass x-y-position (position)
|
|
((x :initform 0 :initarg :x)
|
|
(y :initform 0 :initarg :y)))
|
|
|
|
(defclass rho-theta-position (position)
|
|
((rho :initform 0)
|
|
(theta :initform 0)))
|
|
|
|
(defmethod update-instance-for-different-class :before
|
|
((old x-y-position)
|
|
(new rho-theta-position)
|
|
&key)
|
|
;; Copy the position information from old to new to make new
|
|
;; be a rho-theta-position at the same position as old.
|
|
(let ((x (slot-value old 'x))
|
|
(y (slot-value old 'y)))
|
|
(setf (slot-value new 'rho) (sqrt (+ (* x x) (* y y)))
|
|
(slot-value new 'theta) (atan y x))))
|
|
</pre><P>
|
|
<P><pre>
|
|
;;; At this point an instance of the class x-y-position can be
|
|
;;; changed to be an instance of the class rho-theta-position
|
|
;;; using change-class:
|
|
|
|
(setq p1 (make-instance 'x-y-position :x 2 :y 0))
|
|
|
|
(change-class p1 'rho-theta-position)
|
|
|
|
;;; The result is that the instance bound to p1 is now
|
|
;;; an instance of the class rho-theta-position.
|
|
;;; The update-instance-for-different-class method
|
|
;;; performed the initialization of the rho and theta
|
|
;;; slots based on the values of the x and y slots,
|
|
;;; which were maintained by the old instance.
|
|
</pre><P>
|
|
<P>
|
|
After completing all other actions, <tt>change-class</tt> invokes the generic
|
|
function <tt>update-instance-for-different-class</tt>. The generic function
|
|
<tt>update-instance-for-different-class</tt>
|
|
can be used to assign values to slots in the transformed instance.
|
|
<P>
|
|
The generic function <tt>change-class</tt> has several semantic difficulties.
|
|
First, it performs a destructive operation that can be invoked within a
|
|
method on an instance that was used to select that method. When multiple
|
|
methods are involved because methods are being combined,
|
|
the methods currently executing or about to be executed
|
|
may no longer be applicable. Second, some implementations might use compiler
|
|
optimizations of slot access, and when the class of an instance is
|
|
changed the assumptions the compiler made might be violated.
|
|
This implies that a programmer must not use
|
|
<tt>change-class</tt> inside a method if any methods for that generic function
|
|
access any slots, or the results are undefined.
|
|
<P>
|
|
See section <A HREF="node305.html#ChangingtheClassofanInstanceSECTION">28.1.11</A> as well as
|
|
<tt>update-instance-for-different-class</tt>.
|
|
<P>
|
|
<br><b>[Generic function]</b><BR>
|
|
<tt>class-name <i>class</i> </tt><BR>
|
|
<br><b>[Primary method]</b><br>
|
|
<tt>class-name (<i>class</i> class)</tt>
|
|
<P>The generic function <tt>class-name</tt> takes a class object and returns its
|
|
name.
|
|
The <i>class</i> argument is a class object.
|
|
The <i>new-value</i> argument is any object.
|
|
The name of the given class is returned.
|
|
<P>
|
|
The name of an anonymous class is <tt>nil</tt>.
|
|
<P>
|
|
If <i>S</i> is a symbol such that <i>S</i> <b>=</b><tt>(class-name <i>C</i>)</tt> and <i>C</i> <b>=</b>
|
|
<tt>(find-class <i>S</i>)</tt>, then <i>S</i> is the proper name of <i>C</i> (see section <A HREF="node263.html#ClassesSECTION">28.1.2</A>).
|
|
<P>
|
|
See also section <A HREF="node263.html#ClassesSECTION">28.1.2</A> and <tt>find-class</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>(setf class-name) <i>new-value</i> <i>class</i> </tt><BR>
|
|
<br><b>[Primary method]</b><br>
|
|
<tt>(setf class-name) <i>new-value</i> (<i>class</i> class)</tt><P>The generic function <tt>(setf class-name)</tt> takes a class object and sets
|
|
its name.
|
|
The <i>class</i> argument is a class object.
|
|
The <i>new-value</i> argument is any object.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>class-of <i>object</i></tt><P>The function <tt>class-of</tt> returns the class of which
|
|
the given object is an instance.
|
|
The argument to <tt>class-of</tt> may be any Common Lisp object.
|
|
The function <tt>class-of</tt> returns the class of which
|
|
the argument is an instance.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>compute-applicable-methods <i>generic-function</i> <i>function-arguments</i></tt><P>Given a generic function and a set of arguments, the function
|
|
<tt>compute-applicable-methods</tt> returns the set of methods
|
|
that are applicable for those arguments.
|
|
<P>
|
|
The methods are
|
|
sorted according to precedence order.
|
|
See section <A HREF="node283.html#MethodSelectionandCombinationSECTION">28.1.7</A>.
|
|
<P>
|
|
The <i>generic-function</i> argument must be a generic function object.
|
|
The <i>function-arguments</i> argument is a list of the arguments to
|
|
that generic function.
|
|
The result is a list of the applicable methods in order of precedence.
|
|
See section <A HREF="node283.html#MethodSelectionandCombinationSECTION">28.1.7</A>.
|
|
<P>
|
|
<BR><b>[Macro]</b><BR>
|
|
<pre>
|
|
defclass <i>class-name</i> ({<i>superclass-name</i>}*)
|
|
({<i>slot-specifier</i>}*) <b>[[</b>?<i>class-option</i><b>]]</b>
|
|
<p>
|
|
<i>class-name</i> ::= <i>symbol</i>
|
|
<i>superclass-name</i> ::= <i>symbol</i>
|
|
<i>slot-specifier</i> ::= <i>slot-name</i> | (<i>slot-name</i> <b>[[</b>?<i>slot-option</i><b>]]</b>)
|
|
<i>slot-name</i> ::= <i>symbol</i>
|
|
<i>slot-option</i> ::= {:reader <i>reader-function-name</i>}*
|
|
| {:writer <i>writer-function-name</i>}*
|
|
| {:accessor <i>reader-function-name</i>}*
|
|
| {:allocation <i>allocation-type</i>}*
|
|
| {:initarg <i>initarg-name</i>}*
|
|
| {:initform <i>form</i>}*
|
|
| {:type <i>type-specifier</i>}*
|
|
| {:documentation <i>string</i>}*
|
|
|
|
<i>reader-function-name</i> ::= <i>symbol</i>
|
|
<i>writer-function-name</i> ::= <i>function-name/</i>
|
|
<i>function-name</i> ::= {<i>symbol</i> | (setf <i>symbol</i>)}
|
|
<i>initarg-name</i> ::= <i>symbol</i>
|
|
<i>allocation-type</i> ::= :instance | :class
|
|
<i>class-option</i> ::= (:default-initargs <i>initarg-list</i>)
|
|
| (:documentation <i>string</i>)
|
|
| (:metaclass <i>class-name</i>)
|
|
<i>initarg-list</i> ::= {<i>initarg-name default-initial-value-form</i>}*
|
|
</pre>
|
|
<p>
|
|
The macro <tt>defclass</tt> defines a new named class. It returns the new class
|
|
object as its result.
|
|
<P>
|
|
The syntax of <tt>defclass</tt> provides options for specifying
|
|
initialization arguments for slots, for specifying default
|
|
initialization values for slots, and for requesting that methods on
|
|
specified generic functions be automatically generated for reading and
|
|
writing the values of slots. No reader or writer functions are
|
|
defined by default; their generation must be explicitly requested.
|
|
<P>
|
|
Defining a new class also causes a type of the same name to be
|
|
defined. The predicate <tt>(typep <i>object class-name</i>)</tt> returns
|
|
true if the class of the given object is <i>class-name</i> itself or
|
|
a subclass of the class <i>class-name</i>. A class object can be used
|
|
as a type specifier. Thus <tt>(typep <i>object class</i>)</tt> returns true
|
|
if the class of the <i>object</i> is <i>class</i> itself or a
|
|
subclass of <i>class</i>.
|
|
<P>
|
|
The <i>class-name</i> argument is a non-<tt>nil</tt> symbol. It becomes
|
|
the proper name of the new class. If a class with the same proper
|
|
name already exists and that class is an instance of
|
|
<tt>standard-class</tt>, and if the <tt>defclass</tt> form for the definition of the
|
|
new class specifies a class of class <tt>standard-class</tt>, the definition
|
|
of the existing class is replaced.
|
|
<P>
|
|
Each <i>superclass-name</i> argument is a non-<tt>nil</tt> symbol that
|
|
specifies a direct superclass of the new class. The new class will
|
|
inherit slots and methods from each of its direct superclasses, from
|
|
their direct superclasses, and so on. See
|
|
section <A HREF="node268.html#InheritanceSECTION">28.1.3</A>
|
|
for a discussion of how slots and methods are inherited.
|
|
<P>
|
|
Each <i>slot-specifier</i> argument is the name of the slot or a list
|
|
consisting of the slot name followed by zero or more slot options.
|
|
The <i>slot-name</i> argument is a symbol that is syntactically valid
|
|
for use as a variable name. If there are any duplicate
|
|
slot names, an error is signaled.
|
|
<P>
|
|
The following slot options are available:
|
|
<P>
|
|
<UL><LI>
|
|
The <tt>:reader</tt> slot option specifies that an unqualified method is
|
|
to be defined on the generic function named <i>reader-function-name</i> to read the value of the given slot.
|
|
The <i>reader-function-name</i> argument is a non-<tt>nil</tt>
|
|
symbol. The <tt>:reader</tt> slot option may be specified more than once
|
|
for a given slot.
|
|
<P>
|
|
<LI>
|
|
The <tt>:writer</tt> slot option specifies that an unqualified method is
|
|
to be defined on the generic function named <i>writer-function-name</i> to write the value of the slot. The
|
|
<i>writer-function-name</i> argument is a function-name.
|
|
The <tt>:writer</tt> slot option may be specified more than once for a
|
|
given slot.
|
|
<P>
|
|
<LI>
|
|
The <tt>:accessor</tt> slot option specifies that an unqualified method
|
|
is to be defined on the generic function named <i>reader-function-name</i> to read the value of the given slot
|
|
and that an unqualified method is to be defined on the generic
|
|
function named <tt>(setf <i>reader-function-name</i>)</tt> to be
|
|
used with <tt>setf</tt> to modify the value of the slot. The <i>reader-function-name</i> argument is a non-<tt>nil</tt> symbol.
|
|
The <tt>:accessor</tt> slot option may be specified more than once for a
|
|
given slot.
|
|
<P>
|
|
<LI>
|
|
The <tt>:allocation</tt> slot option is used to specify where storage is
|
|
to be allocated for the given slot. Storage for a slot may be located
|
|
in each instance or in the class object itself, for example. The value of the <i>allocation-type</i> argument can be either the keyword <tt>:instance</tt>
|
|
or the keyword <tt>:class</tt>. The <tt>:allocation</tt> slot option may be
|
|
specified at most once for a given slot. If the <tt>:allocation</tt>
|
|
slot option is not specified, the effect is the same as specifying
|
|
<tt>:allocation :instance</tt>.
|
|
<P>
|
|
<UL><LI>
|
|
If <i>allocation-type</i> is <tt>:instance</tt>, a local slot of the given name
|
|
is allocated in each instance of the class.
|
|
<P>
|
|
<LI>
|
|
If <i>allocation-type</i> is <tt>:class</tt>, a shared slot of the given
|
|
name is allocated. The value of the slot is shared by all instances of the class.
|
|
If a class <b><i>C</i></b> defines such a shared slot, any subclass <b><i>C</i></b> of
|
|
<b><i>C</i></b> will share this single slot unless the <tt>defclass</tt> form
|
|
for <b><i>C</i></b> specifies a slot of the same name or there is a
|
|
superclass of <b><i>C</i></b> that precedes <b><i>C</i></b> in the class precedence
|
|
list of <b><i>C</i></b> and that defines a slot of the same name.
|
|
</UL>
|
|
<P>
|
|
<LI> The <tt>:initform</tt> slot option is used to provide a default
|
|
initial value form to be used in the initialization of the slot. The
|
|
<tt>:initform</tt> slot option may be specified at most once for a given
|
|
slot. This form is evaluated every time it is used to initialize the
|
|
slot. The lexical
|
|
environment in which this form is evaluated is the lexical environment
|
|
in which the <tt>defclass</tt> form was evaluated. Note that the lexical
|
|
environment refers both to variables and to functions. For local
|
|
slots, the dynamic environment is the dynamic environment in which
|
|
<tt>make-instance</tt> was called; for shared slots, the dynamic
|
|
environment is the dynamic environment in which the <tt>defclass</tt>
|
|
form was evaluated. See section <A HREF="node292.html#ObjectCreationandInitializationSECTION">28.1.9</A>.
|
|
<P>
|
|
No implementation is permitted to extend the syntax of <tt>defclass</tt>
|
|
to allow <tt>(<i>slot-name form</i>)</tt> as an abbreviation for
|
|
<tt>(<i>slot-name</i> :initform <i>form</i>)</tt>.
|
|
<P>
|
|
<LI>
|
|
The <tt>:initarg</tt> slot option declares an initialization argument
|
|
named <i>initarg-name</i> and specifies that this initialization argument
|
|
initializes the given slot. If the initialization argument has a
|
|
value in the call to <tt>initialize-instance</tt>, the value will be
|
|
stored into the given slot, and the slot's <tt>:initform</tt> slot option, if
|
|
any, is not evaluated. If none of the initialization arguments
|
|
specified for a given slot has a value, the slot is initialized
|
|
according to the <tt>:initform</tt> slot option, if specified. The
|
|
<tt>:initarg</tt> slot option can be specified more than once for a given
|
|
slot. The <i>initarg-name</i> argument can be any symbol.
|
|
<P>
|
|
<LI>
|
|
The <tt>:type</tt> slot option specifies that the contents of the slot
|
|
will always be of the specified data type. It effectively declares
|
|
the result type of the reader generic function when applied to an
|
|
object of this class. The result of attempting to store in a slot a
|
|
value that does not satisfy the type of the slot is undefined. The
|
|
<tt>:type</tt> slot option may be specified at most once for a given
|
|
slot. The <tt>:type</tt> slot option is further discussed in
|
|
section <A HREF="node270.html#InheritanceofSlotsandSlotOptionsSECTION">28.1.3.2</A>.
|
|
<P>
|
|
<LI>
|
|
The <tt>:documentation</tt> slot option provides a documentation string
|
|
for the slot.
|
|
</UL>
|
|
<P>
|
|
Each class option is an option that refers to the class as a whole
|
|
or to all class slots. The following class options are available:
|
|
<P>
|
|
<UL><LI>
|
|
The <tt>:default-initargs</tt> class option is followed by a list of
|
|
alternating initialization argument names and default initial value
|
|
forms. If any of these initialization arguments does not appear in
|
|
the initialization argument list supplied to <tt>make-instance</tt>, the
|
|
corresponding default initial value form is evaluated, and the
|
|
initialization argument name and the form's value are added to the end
|
|
of the initialization argument list before the instance is created
|
|
(see section <A HREF="node292.html#ObjectCreationandInitializationSECTION">28.1.9</A>). The default
|
|
initial value form is evaluated each time it is used. The lexical
|
|
environment in which this form is evaluated is the lexical environment
|
|
in which the <tt>defclass</tt> form was evaluated. The dynamic
|
|
environment is the dynamic environment in which <tt>make-instance</tt>
|
|
was called. If an initialization argument name appears more than once
|
|
in a <tt>:default-initargs</tt> class option, an error is signaled. The
|
|
<tt>:default-initargs</tt> class option may be specified at most once.
|
|
<P>
|
|
<LI>
|
|
The <tt>:documentation</tt> class option causes a documentation string to be
|
|
attached to the class name. The documentation type for this string is
|
|
<tt>type</tt>. The form <tt>(documentation <i>class-name</i> 'type)</tt>
|
|
may be used to retrieve the documentation string. The
|
|
<tt>:documentation</tt> class option may be specified at most once.
|
|
<P>
|
|
<LI>
|
|
The <tt>:metaclass</tt> class option is used to specify that instances of the
|
|
class being defined are to have a different metaclass than the default
|
|
provided by the system (the class <tt>standard-class</tt>). The <i>class-name</i> argument is the name of the desired metaclass. The
|
|
<tt>:metaclass</tt> class option may be specified at most once.
|
|
<P>
|
|
</UL>
|
|
<P>
|
|
The new class object is returned as the result.
|
|
<P>
|
|
If a class with the same proper name already exists and that class is
|
|
an instance of <tt>standard-class</tt>, and if the <tt>defclass</tt> form for
|
|
the definition of the new class specifies a class of class
|
|
<tt>standard-class</tt>, the existing class is redefined, and instances of it
|
|
(and its subclasses) are updated to the new definition at the time
|
|
that they are next accessed (see section <A HREF="node300.html#RedefiningClassesSECTION">28.1.10</A>).
|
|
<P>
|
|
Note the following rules of <tt>defclass</tt> for standard classes:
|
|
<P>
|
|
<UL><LI>
|
|
It is not required that the superclasses of a class be defined before
|
|
the <tt>defclass</tt> form for that class is evaluated.
|
|
<P>
|
|
<LI>
|
|
All the superclasses of a class must be defined before
|
|
an instance of the class can be made.
|
|
<P>
|
|
<LI>
|
|
A class must be defined before it can be used as a parameter
|
|
specializer in a <tt>defmethod</tt> form.
|
|
<P>
|
|
</UL>
|
|
<P>
|
|
The Object System may be extended to cover situations where these rules are not
|
|
obeyed.
|
|
<P>
|
|
Some slot options are inherited by a class from its superclasses, and
|
|
some can be shadowed or altered by providing a local slot description.
|
|
No class options except <tt>:default-initargs</tt> are inherited. For a
|
|
detailed description of how slots and slot options are inherited, see
|
|
section <A HREF="node270.html#InheritanceofSlotsandSlotOptionsSECTION">28.1.3.2</A>.
|
|
<P>
|
|
The options to <tt>defclass</tt> can be extended.
|
|
An implementation must signal an error if it observes a class option or
|
|
a slot option that is not implemented locally.
|
|
<P>
|
|
It is valid to specify more than one reader, writer, accessor, or
|
|
initialization argument for a slot. No other slot option may appear
|
|
more than once in a single slot description, or an error is
|
|
signaled.
|
|
<P>
|
|
If no reader, writer, or accessor is specified for a slot, the slot
|
|
can be accessed only by the function <tt>slot-value</tt>.
|
|
<P>
|
|
See sections <A HREF="node263.html#ClassesSECTION">28.1.2</A>,
|
|
<A HREF="node268.html#InheritanceSECTION">28.1.3</A>,
|
|
<A HREF="node300.html#RedefiningClassesSECTION">28.1.10</A>,
|
|
<A HREF="node274.html#DeterminingtheClassPrecedenceListSECTION">28.1.5</A>,
|
|
<A HREF="node292.html#ObjectCreationandInitializationSECTION">28.1.9</A> as well as
|
|
<tt>slot-value</tt>,
|
|
<tt>make-instance</tt>, and
|
|
<tt>initialize-instance</tt>.
|
|
<P>
|
|
<BR><b>[Macro]</b><BR>
|
|
<pre>
|
|
defgeneric <i>function-name lambda-list</i>
|
|
<b>[[</b>?<i>option</i> | {<i>method-description</i>}*<b>]]</b>
|
|
|
|
<i>function-name</i> ::= {<i>symbol</i> | (setf <i>symbol</i>)}
|
|
<i>lambda-list</i> ::= ({<i>var</i>}*
|
|
[&optional {<i>var</i> | (<i>var</i>)}*]
|
|
[&rest <i>var</i>]
|
|
[&key {<i>keyword-parameter</i>}* [&allow-other-keys]])
|
|
<i>keyword-parameter</i> ::= <i>var</i> | ({<i>var</i> | (<i>keyword</i> <i>var</i>)})
|
|
<i>option</i> ::= (:argument-precedence-order {<i>parameter-name</i>}+)
|
|
| (declare {<i>declaration</i>}+)
|
|
| (:documentation <i>string</i>)
|
|
| (:method-combination <i>symbol</i> {<i>arg</i>}*)
|
|
| (:generic-function-class <i>class-name</i>)
|
|
| (:method-class <i>class-name</i>)
|
|
<i>method-description</i> ::= (:method {<i>method-qualifier</i>}*
|
|
<i>specialized-lambda-list</i>
|
|
<b>[[</b> {<i>declaration</i>}* | <i>documentation</i> <b>]]</b>
|
|
{<I>form</i>}*)
|
|
<i>method-qualifier</i> ::= <i>non-nil-atom</i>
|
|
<i>specialized-lambda-list</i> ::=
|
|
({<i>var</i> | (<i>var parameter-specializer-name</i>)}*
|
|
[&optional {<i>var</i> | (<i>var</i> [<i>initform</i> [<i>supplied-p-parameter</i>]])}*]
|
|
[&rest <i>var</i>]
|
|
[&key {<i>specialized-keyword-parameter</i>}* [&allow-other-keys]]
|
|
[&aux {<i>var</i> | (<i>var</i> [<i>initform</i>])}*])
|
|
<i>specialized-keyword-parameter</i> ::=
|
|
<i>var</i> | ({<i>var</i> | (<i>keyword</i> <i>var</i>)} [<i>initform</i> [<i>supplied-p-parameter</i>]])
|
|
<i>parameter-specializer-name</i> ::= <i>symbol</i> | (eql <i>eql-specializer-form</i>)
|
|
</pre>
|
|
The macro <tt>defgeneric</tt> is used to define a generic function or to
|
|
specify options and declarations that pertain to a generic function as
|
|
a whole.
|
|
<P>
|
|
If <tt>(fboundp <i>function-name</i>)</tt> is <tt>nil</tt>, a new
|
|
generic function is created. If <tt>(fdefinition <i>function-specifier</i>)</tt> is a generic function, that generic function
|
|
is modified. If <i>function-name/</i> names a non-generic
|
|
function, a macro, or a special form, an error is signaled.
|
|
<P>
|
|
[X3J13 voted in March 1989 (FUNCTION-NAME) <A NAME=34291> </A> to use <tt>fdefinition</tt>
|
|
in the previous paragraph, as shown, rather than <tt>symbol-function</tt>,
|
|
as it appeared in the original report on CLOS [<A HREF="node368.html#SIGPLANCLOS">5</A>,<A HREF="node368.html#LASCCLOSPART2">7</A>].
|
|
The vote also changed all occurrences of <i>function-specifier</i> in the
|
|
original report to <i>function-name</i>; this change is reflected here.-GLS]
|
|
<P>
|
|
Each <i>method-description</i> defines a method on the generic function.
|
|
The lambda-list of each method must be congruent with the lambda-list
|
|
specified by the <i>lambda-list</i> option. If this condition
|
|
does not hold, an error is signaled.
|
|
See section <A HREF="node281.html#CongruentLambdaListsforAllMethodsofaGenericFunctionSECTION">28.1.6.4</A>
|
|
for a definition
|
|
of congruence in this context.
|
|
<P>
|
|
The macro <tt>defgeneric</tt> returns the generic function object
|
|
as its result.
|
|
<P>
|
|
The <i>function-name</i> argument is a non-<tt>nil</tt> symbol or a
|
|
list of the form <tt>(setf <i>symbol</i>)</tt>.
|
|
<P>
|
|
|
|
<P>
|
|
The <i>lambda-list</i> argument is an ordinary function lambda-list
|
|
with the following exceptions:
|
|
<P>
|
|
<UL><LI>
|
|
The use of <tt>&aux</tt> is not allowed.
|
|
<P>
|
|
<LI>
|
|
Optional and keyword arguments may not have default initial value forms
|
|
nor use supplied-p parameters.
|
|
The generic function passes to the method all the argument values passed to
|
|
it, and only those; default values are not supported.
|
|
Note that optional and keyword arguments in method definitions, however,
|
|
can have default initial value forms and can use supplied-p parameters.
|
|
</UL>
|
|
<P>
|
|
The following options are provided. A given option may occur only once,
|
|
or an error is signaled.
|
|
<P>
|
|
<UL><LI>
|
|
The <tt>:argument-precedence-order</tt> option is used to specify the
|
|
order in which the required arguments in a call to the generic
|
|
function are tested for specificity when selecting a particular
|
|
method. Each required argument, as specified in the <i>lambda-list</i>
|
|
argument, must be included exactly once as a <i>parameter-name</i> so that the full and unambiguous precedence order is
|
|
supplied. If this condition is not met, an error is signaled.
|
|
<P>
|
|
<LI>
|
|
The <tt>declare</tt> option is used to specify declarations that pertain
|
|
to the generic function. The following standard Common Lisp
|
|
declaration is allowed:
|
|
<P>
|
|
<UL><LI>
|
|
An <tt>optimize</tt> declaration specifies whether method selection
|
|
should be optimized for speed or space, but it has no effect on
|
|
methods. To control how a method is optimized, an <tt>optimize</tt>
|
|
declaration must be placed directly in the <tt>defmethod</tt> form or
|
|
method description. The optimization qualities <tt>speed</tt> and
|
|
<tt>space</tt> are the only qualities this standard requires, but an
|
|
implementation can extend the Common Lisp Object System to recognize other qualities. A
|
|
simple implementation that has only one method selection technique and
|
|
ignores the <tt>optimize</tt> declaration is valid.
|
|
</UL>
|
|
<P>
|
|
The <tt>special</tt>, <tt>ftype</tt>, <tt>function</tt>, <tt>inline</tt>,
|
|
<tt>notinline</tt>, and <tt>declaration</tt> declarations are not permitted.
|
|
Individual implementations can extend the <tt>declare</tt> option to
|
|
support additional declarations. If an implementation notices a
|
|
declaration that it does not support and that has not been proclaimed
|
|
as a non-standard declaration name in a <tt>declaration</tt> proclamation, it
|
|
should issue a warning.
|
|
<P>
|
|
<LI>
|
|
The <tt>:documentation</tt> argument associates a documentation string
|
|
with the generic function. The documentation type for this string is
|
|
<tt>function</tt>. The form <tt>(documentation <i>function-name/</i> 'function)</tt> may be used to retrieve this
|
|
string.
|
|
<P>
|
|
<LI>
|
|
The <tt>:generic-function-class</tt> option may be used to specify that
|
|
the generic function is to have a different class than the default
|
|
provided by the system (the class <tt>standard-generic-function</tt>).
|
|
The <i>class-name</i> argument is the name of a class that can be the
|
|
class of a generic function. If <i>function-name</i> specifies
|
|
an existing generic function that has a different value for the
|
|
<tt>:generic-function-class</tt> argument and the new generic function class
|
|
is compatible with the old, <tt>change-class</tt> is called to change the
|
|
class of the generic function; otherwise an error is signaled.
|
|
<P>
|
|
<LI>
|
|
The <tt>:method-class</tt> option is used to specify that all methods on
|
|
this generic function are to have a different class from the default
|
|
provided by the system (the class <tt>standard-method</tt>). The <i>class-name</i> argument is the name of a class that is capable of being
|
|
the class of a method.
|
|
<P>
|
|
<LI>
|
|
The <tt>:method-combination</tt> option is followed by a symbol that
|
|
names a type of method combination. The arguments (if any) that
|
|
follow that symbol depend on the type of method combination. Note
|
|
that the standard method combination type does not support any
|
|
arguments. However, all types of method combination defined by the
|
|
short form of <tt>define-method-combination</tt> accept an optional
|
|
argument named <i>order</i>, defaulting to
|
|
<tt>:most-specific-first</tt>, where a value of <tt>:most-specific-last</tt> reverses
|
|
the order of the primary methods without affecting the order of the
|
|
auxiliary methods.
|
|
<P>
|
|
</UL>
|
|
<P>
|
|
The <i>method-description</i> arguments define methods that will
|
|
be associated with the generic function. The <i>method-qualifier</i>
|
|
and <i>specialized-lambda-list</i> arguments in a method description
|
|
are the same as for <tt>defmethod</tt>.
|
|
<P>
|
|
The <i>form</i> arguments specify the method body. The body of the
|
|
method is enclosed in an implicit block. If <i>function-name</i> is a symbol, this block bears the same name as
|
|
the generic function. If <i>function-name</i> is a list of the
|
|
form <tt>(setf <i>symbol</i>)</tt>, the name of the block is <i>symbol</i>.
|
|
<P>
|
|
The generic function object is returned as the result.
|
|
<P>
|
|
The effect of the <tt>defgeneric</tt> macro is as if the following three
|
|
steps were performed: first, methods defined by previous
|
|
<tt>defgeneric</tt> forms are removed; second, <tt>ensure-generic-function</tt>
|
|
is called; and finally, methods specified by the current
|
|
<tt>defgeneric</tt> form are added to the generic function.
|
|
<P>
|
|
If no method descriptions are specified and a generic function of the same
|
|
name does not already exist, a generic function with no methods is created.
|
|
<P>
|
|
The <i>lambda-list</i> argument of
|
|
<tt>defgeneric</tt> specifies the shape of lambda-lists for the methods on
|
|
this generic function. All methods on the resulting generic function must have
|
|
lambda-lists that are congruent with this shape. If a
|
|
<tt>defgeneric</tt> form is evaluated and some methods for that generic
|
|
function have lambda-lists that are not congruent with that given in
|
|
the <tt>defgeneric</tt> form, an error is signaled. For further details
|
|
on method congruence,
|
|
see section <A HREF="node281.html#CongruentLambdaListsforAllMethodsofaGenericFunctionSECTION">28.1.6.4</A>.
|
|
<P>
|
|
Implementations can extend <tt>defgeneric</tt> to include other options.
|
|
It is required that an implementation signal an error if
|
|
it observes an option that is not implemented locally.
|
|
<P>
|
|
See section <A HREF="node281.html#CongruentLambdaListsforAllMethodsofaGenericFunctionSECTION">28.1.6.4</A>
|
|
as well as <tt>defmethod</tt>, <tt>ensure-generic-function</tt>, and <tt>generic-function</tt>.
|
|
<P>
|
|
<BR><b>[Macro]</b><BR>
|
|
<pre>
|
|
define-method-combination <i>name</i> <b>[[</b>?<i>short-form-option</i><b>]]</b>
|
|
define-method-combination <i>name</i> <i>lambda-list</i>
|
|
({<i>method-group-specifier</i>}*)
|
|
[(:arguments . <i>lambda-list</i>)]
|
|
[(:generic-function <i>generic-fn-symbol</i>)]
|
|
<b>[[</b>{<i>declaration</i>}* | <i>doc-string</i><b>]]</b>
|
|
{<i>form</i>}*
|
|
|
|
<i>short-form-option</i> ::= :documentation <i>string</i>
|
|
| :identity-with-one-argument <i>boolean</i>
|
|
| :operator <i>operator</i>
|
|
<i>method-group-specifier</i> ::= (<i>variable</i> {{<i>qualifier-pattern</i>}+ | <i>predicate</i>}
|
|
<b>[[</b>?<i>long-form-option</i><b>]]</b>)
|
|
<i>long-form-option</i> ::= :description <i>format-string</i>
|
|
| :order <i>order</i>
|
|
| :required <i>boolean</i>
|
|
</pre>
|
|
The macro <tt>define-method-combination</tt> is used to define new types
|
|
of method combination.
|
|
<P>
|
|
There are two forms of <tt>define-method-combination</tt>. The short
|
|
form is a simple facility for the cases that are expected
|
|
to be most commonly needed. The long form is more powerful but more
|
|
verbose. It resembles <tt>defmacro</tt> in that the body is an
|
|
expression, usually using backquote, that computes a Lisp form. Thus
|
|
arbitrary control structures can be implemented. The long form also
|
|
allows arbitrary processing of method qualifiers.
|
|
<P>
|
|
In both the short and long forms, <i>name</i> is a symbol. By convention,
|
|
non-keyword, non-<tt>nil</tt> symbols are usually used.
|
|
<P>
|
|
<P>The short-form syntax of <tt>define-method-combination</tt> is recognized
|
|
when the second subform is a non-<tt>nil</tt> symbol or is not present.
|
|
When the short form is used, <i>name</i> is defined as a type of
|
|
method combination that produces a Lisp form <tt>(<i>operator
|
|
method-call method-call <b>...</b> </i>)</tt>. The <i>operator</i> is a symbol
|
|
that can be the name of a function, macro, or special form. The
|
|
<i>operator</i> can be specified by a keyword option; it defaults to <i>name</i>.
|
|
<P>
|
|
Keyword options for the short form are the following:
|
|
<P>
|
|
<UL><LI>
|
|
The <tt>:documentation</tt> option is used to document the method-combination type.
|
|
<P>
|
|
<LI>
|
|
The <tt>:identity-with-one-argument</tt> option enables an optimization
|
|
when <i>boolean</i> is true (the default is false). If there is
|
|
exactly one applicable method and it is a primary method, that method
|
|
serves as the effective method and <i>operator</i> is not called.
|
|
This optimization avoids the need to create a new effective method and
|
|
avoids the overhead of a function call. This option is designed to be
|
|
used with operators such as <tt>progn</tt>, <tt>and</tt>, <tt>+</tt>, and
|
|
<tt>max</tt>.
|
|
<P>
|
|
<LI>
|
|
The <tt>:operator</tt> option specifies the name of the operator. The
|
|
<i>operator</i> argument is a symbol that can be the name of a
|
|
function, macro, or special form. By convention, <i>name</i> and
|
|
<i>operator</i> are often the same symbol. This is the default,
|
|
but it is not required.
|
|
<P>
|
|
</UL>
|
|
<P>
|
|
None of the subforms is evaluated.
|
|
<P>
|
|
These types of method combination require exactly one qualifier per
|
|
method. An error is signaled if there are applicable methods with no
|
|
qualifiers or with qualifiers that are not supported by the method
|
|
combination type.
|
|
<P>
|
|
A method combination procedure defined in this way recognizes two
|
|
roles for methods. A method whose one qualifier is the symbol naming
|
|
this type of method combination is defined to be a primary method. At
|
|
least one primary method must be applicable or an error is signaled.
|
|
A method with <tt>:around</tt> as its one qualifier is an auxiliary
|
|
method that behaves the same as an <tt>:around</tt> method in standard
|
|
method combination. The function <tt>call-next-method</tt> can be
|
|
used only in <tt>:around</tt> methods; it cannot be used in primary methods
|
|
defined by the short form of the <tt>define-method-combination</tt> macro.
|
|
<P>
|
|
A method combination procedure defined in this way accepts an optional
|
|
argument named <i>order</i>, which defaults to
|
|
<tt>:most-specific-first</tt>. A value of <tt>:most-specific-last</tt> reverses
|
|
the order of the primary methods without affecting the order of the
|
|
auxiliary methods.
|
|
<P>
|
|
The short form automatically includes error checking and support for
|
|
<tt>:around</tt> methods.
|
|
<P>
|
|
For a discussion of built-in method combination types,
|
|
see section <A HREF="node287.html#BuiltinMethodCombinationTypesSECTION">28.1.7.4</A>.
|
|
<P>
|
|
<P>The long-form syntax of <tt>define-method-combination</tt> is recognized
|
|
when the second subform is a list.
|
|
<P>
|
|
The <i>lambda-list</i> argument is an ordinary lambda-list. It
|
|
receives any arguments provided after the name of the method
|
|
combination type in the <tt>:method-combination</tt> option to
|
|
<tt>defgeneric</tt>.
|
|
<P>
|
|
A list of method group specifiers follows. Each specifier selects a subset
|
|
of the applicable methods to play a particular role, either by matching
|
|
their qualifiers against some patterns or by testing their qualifiers with
|
|
a predicate. These method group specifiers define all method qualifiers
|
|
that can be used with this type of method combination. If an applicable
|
|
method does not fall into any method group, the system signals the error
|
|
that the method is invalid for the kind of method combination in use.
|
|
<P>
|
|
Each method group specifier names a variable. During the execution of
|
|
the forms in the body of <tt>define-method-combination</tt>, this
|
|
variable is bound to a list of the methods in the method group. The
|
|
methods in this list occur in most-specific-first order.
|
|
<P>
|
|
A qualifier pattern is a list or the symbol <tt>*</tt>. A method matches
|
|
a qualifier pattern if the method's list of qualifiers is <tt>equal</tt>
|
|
to the qualifier pattern (except that the symbol <tt>*</tt> in a qualifier
|
|
pattern matches anything). Thus a qualifier pattern can be one of the
|
|
following: the empty list <tt>()</tt>, which matches unqualified methods;
|
|
the symbol <tt>*</tt>, which matches all methods; a true list, which
|
|
matches methods with the same number of qualifiers as the length of
|
|
the list when each qualifier matches the corresponding list element;
|
|
or a dotted list that ends in the symbol <tt>*</tt> (the <tt>*</tt> matches
|
|
any number of additional qualifiers).
|
|
<P>
|
|
Each applicable method is tested against the qualifier patterns and
|
|
predicates in left-to-right order. As soon as a qualifier pattern matches
|
|
or a predicate returns true, the method becomes a member of the
|
|
corresponding method group and no further tests are made. Thus if a method
|
|
could be a member of more than one method group, it joins only the first
|
|
such group. If a method group has more than one qualifier pattern, a
|
|
method need only satisfy one of the qualifier patterns to be a member of
|
|
the group.
|
|
<P>
|
|
The name of a predicate function can appear instead of qualifier
|
|
patterns in a method group specifier. The predicate is called for
|
|
each method that has not been assigned to an earlier method group; it
|
|
is called with one argument, the method's qualifier list. The
|
|
predicate should return true if the method is to be a member of the
|
|
method group. A predicate can be distinguished from a qualifier pattern
|
|
because it is a symbol other than <tt>nil</tt> or <tt>*</tt>.
|
|
<P>
|
|
If there is an applicable method whose qualifiers are not valid
|
|
for the method combination type, the function <tt>invalid-method-error</tt>
|
|
is called.
|
|
<P>
|
|
Method group specifiers can have keyword options following the
|
|
qualifier patterns or predicate. Keyword options can be distinguished from
|
|
additional qualifier patterns because they are neither lists nor the symbol
|
|
<tt>*</tt>. The keyword options are:
|
|
<UL><LI>
|
|
The <tt>:description</tt> option is used to provide a description of the
|
|
role of methods in the method group. Programming environment tools
|
|
use <tt>(apply #'format stream <i>format-string</i>
|
|
(method-qualifiers <i>method</i>))</tt> to print this description, which
|
|
is expected to be concise. This keyword
|
|
option allows the description of a method qualifier to be defined in
|
|
the same module that defines the meaning of the method
|
|
qualifier. In most cases, <i>format-string</i> will not contain any
|
|
<tt>format</tt> directives, but they are available for generality. If
|
|
<tt>:description</tt> is not specified, a default description is generated
|
|
based on the variable name and the qualifier patterns and on whether
|
|
this method group includes the unqualified methods. The argument <i>format-string</i> is not evaluated.
|
|
<P>
|
|
<LI>
|
|
The <tt>:order</tt> option specifies the order of methods. The <i>order</i> argument is a form that evaluates to
|
|
<tt>:most-specific-first</tt> or <tt>:most-specific-last</tt>. If it evaluates
|
|
to any other value, an error is signaled. This keyword option is a
|
|
convenience and does not add any expressive power.
|
|
If <tt>:order</tt> is not specified, it defaults to <tt>:most-specific-first</tt>.
|
|
<P>
|
|
<LI>
|
|
The <tt>:required</tt> option specifies whether at least one method in
|
|
this method group is required. If the <i>boolean</i> argument is
|
|
non-<tt>nil</tt> and the method group is empty (that is, no applicable
|
|
methods match the qualifier patterns or satisfy the predicate), an
|
|
error is signaled. This keyword option is a convenience and does not
|
|
add any expressive power. If <tt>:required</tt> is not specified,
|
|
it defaults to <tt>nil</tt>. The <i>boolean</i> argument is not
|
|
evaluated.
|
|
<P>
|
|
</UL>
|
|
<P>
|
|
The use of method group specifiers provides a convenient syntax to
|
|
select methods, to divide them among the possible roles, and to perform the
|
|
necessary error checking. It is possible to perform further filtering
|
|
of methods in the body forms by using normal list-processing operations
|
|
and the functions <tt>method-qualifiers</tt> and
|
|
<tt>invalid-method-error</tt>. It is permissible to use <tt>setq</tt> on the
|
|
variables named in the method group specifiers and to bind additional
|
|
variables. It is also possible to bypass the method group specifier
|
|
mechanism and do everything in the body forms. This is accomplished
|
|
by writing a single method group with <tt>*</tt> as its only qualifier
|
|
pattern; the variable is then bound to a list of all of the applicable
|
|
methods, in most-specific-first order.
|
|
<P>
|
|
The body <i>forms</i> compute and return the Lisp form that specifies
|
|
how the methods are combined, that is, the effective method. The
|
|
effective method uses the macro <tt>call-method</tt>. The definition of this macro has
|
|
lexical scope and is available only in an effective method form.
|
|
Given a method object in one of the lists produced by the method group
|
|
specifiers and a list of next methods, the macro <tt>call-method</tt>
|
|
will invoke the method so that <tt>call-next-method</tt> will have available
|
|
the next methods.
|
|
<P>
|
|
When an effective method has no effect other than to call a single
|
|
method, some implementations employ an optimization that uses the
|
|
single method directly as the effective method, thus avoiding the need
|
|
to create a new effective method. This optimization is active when
|
|
the effective method form consists entirely of an invocation of
|
|
the <tt>call-method</tt> macro whose first subform is a method object and
|
|
whose second subform is <tt>nil</tt>. Each
|
|
<tt>define-method-combination</tt> body is responsible for stripping off
|
|
redundant invocations of <tt>progn</tt>, <tt>and</tt>,
|
|
<tt>multiple-value-prog1</tt>, and the like, if this optimization is desired.
|
|
<P>
|
|
The list <tt>(:arguments . <i>lambda-list</i>)</tt> can appear before
|
|
any declaration or documentation string. This form is useful when
|
|
the method combination type performs some specific behavior as part of
|
|
the combined method and that behavior needs access to the arguments to
|
|
the generic function. Each parameter variable defined by <i>lambda-list</i> is bound to a form that can be inserted into the
|
|
effective method. When this form is evaluated during execution of the
|
|
effective method, its value is the corresponding argument to the
|
|
generic function. If <i>lambda-list</i> is not congruent to the
|
|
generic function's lambda-list, additional ignored parameters are
|
|
automatically inserted until it is congruent. Thus it is permissible
|
|
for <i>lambda-list</i> to receive fewer arguments than the number
|
|
that the generic function expects.
|
|
<P>
|
|
Erroneous conditions detected by the body should be reported with
|
|
<tt>method-combination-error</tt> or
|
|
<tt>invalid-method-error</tt>; these functions
|
|
add any necessary contextual information to the error message and will
|
|
signal the appropriate error.
|
|
<P>
|
|
The body <i>forms</i> are evaluated inside the bindings created by the
|
|
lambda-list and method group specifiers. Declarations at the head of
|
|
the body are positioned directly inside bindings created by the
|
|
lambda-list and outside the bindings of the method group variables.
|
|
Thus method group variables cannot be declared.
|
|
<P>
|
|
Within the body <i>forms</i>, <i>generic-function-symbol</i>
|
|
is bound to the generic function object.
|
|
<P>
|
|
If a <i>doc-string</i> argument is present, it provides the
|
|
documentation for the method combination type.
|
|
<P>
|
|
The functions <tt>method-combination-error</tt> and
|
|
<tt>invalid-method-error</tt> can be called from the body <i>forms</i> or
|
|
from functions called by the body <i>forms</i>. The actions of these
|
|
two functions can depend on implementation-dependent dynamic variables
|
|
automatically bound before the generic function
|
|
<tt>compute-effective-method</tt> is called.
|
|
<P>
|
|
Note that two methods with identical specializers, but with different
|
|
qualifiers, are not ordered by the algorithm described in step 2 of
|
|
the method selection and combination process described in
|
|
section <A HREF="node283.html#MethodSelectionandCombinationSECTION">28.1.7</A>.
|
|
Normally the two methods play
|
|
different roles in the effective method because they have different
|
|
qualifiers, and no matter how they are ordered in the result of step 2
|
|
the effective method is the same. If the two methods play the same
|
|
role and their order matters, an error is signaled. This happens as
|
|
part of the qualifier pattern matching in
|
|
<tt>define-method-combination</tt>.
|
|
<P>
|
|
|
|
<P>
|
|
The value returned by the <tt>define-method-combination</tt> macro is the new
|
|
method combination object.
|
|
<P>
|
|
Most examples of the long form of <tt>define-method-combination</tt> also
|
|
illustrate the use of the related functions that are provided as part
|
|
of the declarative method combination facility.
|
|
<P>
|
|
<pre>
|
|
;;; Examples of the short form of define-method-combination
|
|
|
|
(define-method-combination and :identity-with-one-argument t)
|
|
|
|
(defmethod func and ((x class1) y)
|
|
...)
|
|
|
|
;;; The equivalent of this example in the long form is:
|
|
|
|
(define-method-combination and
|
|
(&optional (order ':most-specific-first))
|
|
((around (:around))
|
|
(primary (and) :order order :required t))
|
|
(let ((form (if (rest primary)
|
|
`(and ,@(mapcar #'(lambda (method)
|
|
`(call-method ,method ()))
|
|
primary))
|
|
`(call-method ,(first primary) ()))))
|
|
(if around
|
|
`(call-method ,(first around)
|
|
(,@(rest around)
|
|
(make-method ,form)))
|
|
form)))
|
|
|
|
|
|
;;; Examples of the long form of define-method-combination
|
|
|
|
;;; The default method-combination technique
|
|
|
|
(define-method-combination standard ()
|
|
((around (:around))
|
|
(before (:before))
|
|
(primary () :required t)
|
|
(after (:after)))
|
|
(flet ((call-methods (methods)
|
|
(mapcar #'(lambda (method)
|
|
`(call-method ,method ()))
|
|
methods)))
|
|
(let ((form (if (or before after (rest primary))
|
|
`(multiple-value-prog1
|
|
(progn ,@(call-methods before)
|
|
(call-method ,(first primary)
|
|
,(rest primary)))
|
|
,@(call-methods (reverse after)))
|
|
`(call-method ,(first primary) ()))))
|
|
(if around
|
|
`(call-method ,(first around)
|
|
(,@(rest around)
|
|
(make-method ,form)))
|
|
form))))
|
|
|
|
;;; A simple way to try several methods until one returns non-nil
|
|
|
|
(define-method-combination or ()
|
|
((methods (or)))
|
|
`(or ,@(mapcar #'(lambda (method)
|
|
`(call-method ,method ()))
|
|
methods)))
|
|
|
|
;;; A more complete version of the preceding
|
|
|
|
(define-method-combination or
|
|
(&optional (order ':most-specific-first))
|
|
((around (:around))
|
|
(primary (or)))
|
|
;; Process the order argument
|
|
(case order
|
|
(:most-specific-first)
|
|
(:most-specific-last (setq primary (reverse primary)))
|
|
(otherwise (method-combination-error
|
|
"~S is an invalid order.~@
|
|
:most-specific-first and :most-specific-last ~
|
|
are the possible values."
|
|
order)))
|
|
;; Must have a primary method
|
|
(unless primary
|
|
(method-combination-error "A primary method is required."))
|
|
;; Construct the form that calls the primary methods
|
|
(let ((form (if (rest primary)
|
|
`(or ,@(mapcar #'(lambda (method)
|
|
`(call-method ,method ()))
|
|
primary))
|
|
`(call-method ,(first primary) ()))))
|
|
;; Wrap the around methods around that form
|
|
(if around
|
|
`(call-method ,(first around)
|
|
(,@(rest around)
|
|
(make-method ,form)))
|
|
form)))
|
|
|
|
;;; The same thing, using the :order and :required keyword options
|
|
(define-method-combination or
|
|
(&optional (order ':most-specific-first))
|
|
((around (:around))
|
|
(primary (or) :order order :required t))
|
|
(let ((form (if (rest primary)
|
|
`(or ,@(mapcar #'(lambda (method)
|
|
`(call-method ,method ()))
|
|
primary))
|
|
`(call-method ,(first primary) ()))))
|
|
(if around
|
|
`(call-method ,(first around)
|
|
(,@(rest around)
|
|
(make-method ,form)))
|
|
form)))
|
|
|
|
;;; This short-form call is behaviorally identical to the preceding.
|
|
(define-method-combination or :identity-with-one-argument t)
|
|
|
|
;;; Order methods by positive integer qualifiers; note that :around
|
|
;;; methods are disallowed here in order to keep the example small.
|
|
|
|
(define-method-combination example-method-combination ()
|
|
((methods positive-integer-qualifier-p))
|
|
`(progn ,@(mapcar #'(lambda (method)
|
|
`(call-method ,method ()))
|
|
(stable-sort methods #'<
|
|
:key #'(lambda (method)
|
|
(first (method-qualifiers
|
|
method)))))))
|
|
|
|
(defun positive-integer-qualifier-p (method-qualifiers)
|
|
(and (= (length method-qualifiers) 1)
|
|
(typep (first method-qualifiers) '(integer 0 *))))
|
|
|
|
;;; Example of the use of :arguments
|
|
(define-method-combination progn-with-lock ()
|
|
((methods ()))
|
|
(:arguments object)
|
|
`(unwind-protect
|
|
(progn (lock (object-lock ,object))
|
|
,@(mapcar #'(lambda (method)
|
|
`(call-method ,method ()))
|
|
methods))
|
|
(unlock (object-lock ,object))))
|
|
</pre><P>
|
|
<P>
|
|
The <tt>:method-combination</tt> option of <tt>defgeneric</tt> is used to
|
|
specify that a generic function should use a particular method
|
|
combination type. The argument to the <tt>:method-combination</tt>
|
|
option is the name of a method combination type.
|
|
<P>
|
|
See sections <A HREF="node283.html#MethodSelectionandCombinationSECTION">28.1.7</A> and
|
|
<A HREF="node287.html#BuiltinMethodCombinationTypesSECTION">28.1.7.4</A> as well as
|
|
<tt>call-method</tt>,
|
|
<tt>method-qualifiers</tt>,
|
|
<tt>method-combination-error</tt>,
|
|
<tt>invalid-method-error</tt>,
|
|
and <tt>defgeneric</tt>.
|
|
<P>
|
|
<br><b>[Macro]</b><BR>
|
|
<pre>
|
|
defmethod <i>function-name</i> {<i>method-qualifier</i>}*
|
|
<i>specialized-lambda-list</i>
|
|
<b>[[</b> {<i>declaration</i>}* | <i>doc-string</i><b>]]</b>
|
|
{<i>form</i>}*
|
|
|
|
<i>function-name</i> ::= {<i>symbol</i> | (setf <i>symbol</i>)}
|
|
<i>method-qualifier</i> ::= <i>non-nil-atom</i>
|
|
<i>parameter-specializer-name</i> ::= <i>symbol</i> | (eql <i>eql-specializer-form</i>)
|
|
</pre>
|
|
The macro <tt>defmethod</tt> defines a method on a generic function.
|
|
<P>
|
|
If <tt>(fboundp <i>function-name</i>)</tt> is <tt>nil</tt>, a generic
|
|
function is created with default values for the argument precedence
|
|
order (each argument is more specific than the arguments to its right
|
|
in the argument list), for the generic function class (the class
|
|
<tt>standard-generic-function</tt>), for the method class (the class
|
|
<tt>standard-method</tt>), and for the method combination type (the standard
|
|
method combination type). The lambda-list of the generic function is
|
|
congruent with the lambda-list of the method being defined; if the
|
|
<tt>defmethod</tt> form mentions keyword arguments, the lambda-list of
|
|
the generic function will mention <tt>&key</tt> (but no keyword
|
|
arguments). If <i>function-name</i> names a non-generic
|
|
function, a macro, or a special form, an error is signaled.
|
|
<P>
|
|
If a generic function is currently named by <i>function-name</i>, where <i>function-name</i> is a symbol or
|
|
a list of the form <tt>(setf <i>symbol</i>)</tt>, the lambda-list of the
|
|
method must be congruent with the lambda-list of the generic function.
|
|
If this condition does not hold, an error is signaled. See
|
|
section <A HREF="node281.html#CongruentLambdaListsforAllMethodsofaGenericFunctionSECTION">28.1.6.4</A>
|
|
for a definition of congruence in this context.
|
|
<P>
|
|
The <i>function-name</i> argument is a non-<tt>nil</tt> symbol or a
|
|
list of the form <tt>(setf <i>symbol</i>)</tt>. It names the generic
|
|
function on which the method is defined.
|
|
<P>
|
|
Each <i>method-qualifier</i> argument is an object that is used by
|
|
method combination to identify the given method. A method qualifier
|
|
is a non-<tt>nil</tt> atom. The method combination type may further
|
|
restrict what a method qualifier may be. The standard method
|
|
combination type allows for unqualified methods or methods whose sole
|
|
qualifier is the keyword <tt>:before</tt>, the keyword
|
|
<tt>:after</tt>, or the keyword <tt>:around</tt>.
|
|
<P>
|
|
A <i>specialized-lambda-list</i> is like an ordinary
|
|
function lambda-list except that the name of a required parameter can
|
|
be replaced by a specialized parameter, a
|
|
list of the form <tt>(<i>variable-name
|
|
parameter-specializer-name</i>)</tt>. Only required parameters may be
|
|
specialized. A parameter specializer name is a symbol that names a
|
|
class or <tt>(eql <i>eql-specializer-form</i>)</tt>. The parameter
|
|
specializer name <tt>(eql <i>eql-specializer-form</i>)</tt> indicates
|
|
that the corresponding argument must be <tt>eql</tt> to the object that
|
|
is the value of <i>eql-specializer-form</i> for the method to be
|
|
applicable. If no parameter specializer name is specified for a given
|
|
required parameter, the parameter specializer defaults to the class
|
|
named <tt>t</tt>. See section <A HREF="node279.html#IntroductiontoMethodsSECTION">28.1.6.2</A>.
|
|
<P>
|
|
The <i>form</i> arguments specify the method body.
|
|
The body of the method is enclosed in an implicit block. If
|
|
<i>function-name</i> is a symbol, this block bears the same name as the
|
|
generic function. If <i>function-name</i> is a list of the form
|
|
<tt>(setf <i>symbol</i>)</tt>, the name of the block is <i>symbol</i>.
|
|
<P>
|
|
The result of <tt>defmethod</tt> is the method object.
|
|
<P>
|
|
The class of the method object that is created is that given by the
|
|
method class option of the generic function on which the method is defined.
|
|
<P>
|
|
If the generic function already has a method that agrees with the
|
|
method being defined on parameter specializers and qualifiers,
|
|
<tt>defmethod</tt> replaces the existing method with the one now being
|
|
defined. See
|
|
section <A HREF="node280.html#AgreementonParameterSpecializersandQualifiersSECTION">28.1.6.3</A>
|
|
for a definition of agreement in this context.
|
|
<P>
|
|
The parameter specializers are derived from the parameter specializer
|
|
names as described in section <A HREF="node279.html#IntroductiontoMethodsSECTION">28.1.6.2</A>.
|
|
<P>
|
|
The expansion of the <tt>defmethod</tt> macro refers to each
|
|
specialized parameter (see the <tt>ignore</tt> declaration specifier), including
|
|
parameters that
|
|
have an explicit parameter specializer name of <tt>t</tt>. This means
|
|
that a compiler warning does not occur if the body of the method does
|
|
not refer to a specialized parameter. Note that a parameter that
|
|
specializes on <tt>t</tt> is not synonymous with an unspecialized
|
|
parameter in this context.
|
|
<P>
|
|
See sections <A HREF="node279.html#IntroductiontoMethodsSECTION">28.1.6.2</A>,
|
|
<A HREF="node281.html#CongruentLambdaListsforAllMethodsofaGenericFunctionSECTION">28.1.6.4</A>,
|
|
and <A HREF="node280.html#AgreementonParameterSpecializersandQualifiersSECTION">28.1.6.3</A>.
|
|
<P>
|
|
[At this point the original CLOS report [<A HREF="node368.html#SIGPLANCLOS">5</A>,<A HREF="node368.html#LASCCLOSPART2">7</A>]
|
|
contained a specification for <tt>describe</tt> as a generic function.
|
|
This specification is omitted here because X3J13 voted in March 1989 (DESCRIBE-UNDERSPECIFIED) <A NAME=34637> </A>
|
|
not to make <tt>describe</tt> a generic function after all (see <tt>describe-object</tt>).-GLS]
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>documentation x &optional doc-type </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<pre>
|
|
documentation (<i>method</i> standard-method) &optional <i>doc-type</i>
|
|
documentation (<i>generic-function</i> standard-generic-function)
|
|
&optional <i>doc-type</i>
|
|
documentation (<i>class</i> standard-class) &optional <i>doc-type</i>
|
|
documentation (<i>method-combination</i> method-combination)
|
|
&optional <i>doc-type</i>
|
|
documentation (<i>slot-description</i> standard-slot-description)
|
|
&optional <i>doc-type</i>
|
|
documentation (<i>symbol</i> symbol) &optional <i>doc-type</i>
|
|
documentation (<i>list</i> list) &optional <i>doc-type</i>
|
|
</pre>
|
|
<P>The ordinary function <tt>documentation</tt> (see section <A HREF="node229.html#DOCUMENTATIONSECTION">25.2</A>)
|
|
is replaced by a generic
|
|
function. The generic function <tt>documentation</tt> returns the
|
|
documentation string associated with the given object if it is
|
|
available; otherwise <tt>documentation</tt> returns <tt>nil</tt>.
|
|
<P>
|
|
The first argument of <tt>documentation</tt> is a symbol, a
|
|
function-name list of the form <tt>(setf <i>symbol</i>)</tt>, a
|
|
method object, a class object, a generic function object, a method
|
|
combination object, or a slot description object.
|
|
Whether a second argument should be supplied depends on the
|
|
type of the first argument.
|
|
<UL><LI>
|
|
If the first argument is a method object, a class object, a generic
|
|
function object, a method combination object, or a slot description
|
|
object, the second argument must not be supplied, or an error is
|
|
signaled.
|
|
<P>
|
|
<LI>
|
|
If the first argument is a symbol or a list of the form
|
|
<tt>(setf <i>symbol</i>)</tt>, the second argument must be
|
|
supplied.
|
|
<P>
|
|
<UL><LI>
|
|
The forms
|
|
<P><pre>
|
|
(documentation <i>symbol</i> 'function)
|
|
</pre><P>
|
|
and
|
|
<P><pre>
|
|
(documentation '(setf <i>symbol</i>) 'function)
|
|
</pre><P>
|
|
return the
|
|
documentation string of the function, generic function, special form, or
|
|
macro named by the symbol or list.
|
|
<P>
|
|
<LI>
|
|
The form <tt>(documentation <i>symbol</i> 'variable)</tt> returns the
|
|
documentation string of the special variable or constant named by the
|
|
symbol.
|
|
<P>
|
|
<LI>
|
|
The form <tt>(documentation <i>symbol</i> 'structure)</tt> returns the
|
|
documentation string of the <tt>defstruct</tt> structure named by the
|
|
symbol.
|
|
<P>
|
|
<LI>
|
|
The form <tt>(documentation <i>symbol</i> 'type)</tt> returns the documentation
|
|
string of the class object named by the symbol, if there is such a
|
|
class. If there is no such class, it returns the documentation string
|
|
of the type specifier named by the symbol.
|
|
<P>
|
|
<LI>
|
|
The form <tt>(documentation <i>symbol</i> 'setf)</tt> returns the documentation
|
|
string of the <tt>defsetf</tt> or <tt>define-setf-method</tt> definition
|
|
associated with the symbol.
|
|
<P>
|
|
<LI>
|
|
The form <tt>(documentation <i>symbol</i> 'method-combination)</tt> returns the
|
|
documentation string of the method combination type named by the
|
|
symbol.
|
|
</UL>
|
|
<P>
|
|
</UL>
|
|
<P>
|
|
An implementation may extend the set of symbols that are acceptable as
|
|
the second argument. If a symbol is not recognized as an acceptable
|
|
argument by the implementation, an error must be signaled.
|
|
<P>
|
|
The documentation string associated with the given object is returned
|
|
unless none is available, in which case <tt>documentation</tt> returns
|
|
<tt>nil</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
(setf documentation) <i>new-value</i> <i>x</i> &optional <i>doc-type</i> <BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<pre>
|
|
(setf documentation) <i>new-value</i>
|
|
(<i>method</i> standard-method) &optional <i>doc-type</i>
|
|
(setf documentation) <i>new-value</i>
|
|
(<i>generic-function</i> standard-generic-function) &optional <i>doc-type</i>
|
|
(setf documentation) <i>new-value</i>
|
|
(<i>class</i> standard-class) &optional <i>doc-type</i>
|
|
(setf documentation) <i>new-value</i>
|
|
(<i>method-combination</i> method-combination) &optional <i>doc-type</i>
|
|
(setf documentation) <i>new-value</i>
|
|
(<i>slot-description</i> standard-slot-description) &optional <i>doc-type</i>
|
|
(setf documentation) <i>new-value</i>
|
|
(<i>symbol</i> symbol) &optional <i>doc-type</i>
|
|
(setf documentation) <i>new-value</i>
|
|
(<i>list</i> list) &optional <i>doc-type</i>
|
|
</pre>
|
|
<P>The generic function <tt>(setf documentation)</tt> is used to update the
|
|
documentation.
|
|
<P>
|
|
The first argument of <tt>(setf documentation)</tt> is the new documentation.
|
|
<P>
|
|
The second argument of <tt>documentation</tt> is a symbol, a
|
|
function-name list of the form <tt>(setf <i>symbol</i>)</tt>, a
|
|
method object, a class object, a generic function object, a method
|
|
combination object, or a slot description object.
|
|
Whether a third argument should be supplied depends on the
|
|
type of the second argument.
|
|
See <tt>documentation</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>ensure-generic-function <i>function-name</i> &key :lambda-list</tt><tt>:argument-precedence-order</tt><tt>:declare</tt><tt>:documentation</tt><tt>:generic-function-class</tt><tt>:method-combination</tt><tt>:method-class</tt><tt>:environment</tt>
|
|
<P>
|
|
<PRE>
|
|
<i>function-name</i> ::= {<i>symbol</i> | (setf <i>symbol</i>)}
|
|
</PRE>
|
|
The function <tt>ensure-generic-function</tt> is used to define a
|
|
globally named generic function with no methods or to specify or
|
|
modify options and declarations that pertain to a globally named
|
|
generic function as a whole.
|
|
<P>
|
|
If <tt>(fboundp <i>function-name</i>)</tt> is <tt>nil</tt>, a new
|
|
generic function is created. If <tt>(fdefinition <i>function-name</i>)</tt> is a non-generic function, a macro, or a
|
|
special form, an error is signaled.
|
|
<P>
|
|
[X3J13 voted in March 1989 (FUNCTION-NAME) <A NAME=34688> </A> to use <tt>fdefinition</tt>
|
|
in the previous paragraph, as shown, rather than <tt>symbol-function</tt>,
|
|
as it appeared in the original report on CLOS [<A HREF="node368.html#SIGPLANCLOS">5</A>,<A HREF="node368.html#LASCCLOSPART2">7</A>].
|
|
The vote also changed all occurrences of <i>function-specifier</i> in the
|
|
original report to <i>function-name</i>; this change is reflected here.-GLS]
|
|
<P>
|
|
If <i>function-name</i> specifies a generic function that has a
|
|
different value for any of the following arguments, the generic
|
|
function is modified to have the new value:
|
|
<tt>:argument-precedence-order</tt>, <tt>:declare</tt>, <tt>:documentation</tt>,
|
|
<tt>:method-combination</tt>.
|
|
<P>
|
|
If <i>function-name</i> specifies a generic function that has a
|
|
different value for the <tt>:lambda-list</tt> argument, and the new value
|
|
is congruent with the lambda-lists of all existing methods or there
|
|
are no methods, the value is changed; otherwise an error is signaled.
|
|
<P>
|
|
If <i>function-name</i> specifies a generic function that has a
|
|
different value for the <tt>:generic-function-class</tt> argument and if
|
|
the new generic function class is compatible with the old,
|
|
<tt>change-class</tt> is called to change the class of the generic function;
|
|
otherwise an error is signaled.
|
|
<P>
|
|
If <i>function-name</i> specifies a generic function that has a
|
|
different <tt>:method-class</tt> value, the value is
|
|
changed but any existing methods are not changed.
|
|
<P>
|
|
The <i>function-name</i> argument is a symbol or a list of the
|
|
form <tt>(setf <i>symbol</i>)</tt>.
|
|
<P>
|
|
The keyword arguments correspond to the <i>option</i> arguments of
|
|
<tt>defgeneric</tt>, except that the <tt>:method-class</tt> and
|
|
<tt>:generic-function-class</tt> arguments can be class objects
|
|
as well as names.
|
|
<P>
|
|
The <tt>:environment</tt> argument is the same as the
|
|
<tt>&environment</tt> argument to macro expansion functions. It is typically
|
|
used to distinguish between compile-time and run-time environments.
|
|
<P>
|
|
The <tt>:method-combination</tt> argument is a method combination object.
|
|
<P>
|
|
The generic function object is returned.
|
|
See <tt>defgeneric</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>find-class <i>symbol</i> &optional <i>errorp</i> <i>environment</i></tt><P>The function <tt>find-class</tt> returns the class object named by the
|
|
given symbol in the given environment.
|
|
<P>
|
|
The first argument to <tt>find-class</tt> is a symbol.
|
|
<P>
|
|
If there is no such class and the <i>errorp</i> argument is
|
|
not supplied or is non-<tt>nil</tt>, <tt>find-class</tt> signals an error.
|
|
If there is no such class and the <i>errorp</i> argument is
|
|
<tt>nil</tt>, <tt>find-class</tt> returns <tt>nil</tt>. The default value of
|
|
<i>errorp</i> is <tt>t</tt>.
|
|
<P>
|
|
The optional <i>environment</i> argument is the same as the
|
|
<tt>&environment</tt> argument to macro expansion functions. It is typically
|
|
used to distinguish between compile-time and run-time environments.
|
|
<P>
|
|
The result of <tt>find-class</tt> is the class object named by the given symbol.
|
|
<P>
|
|
The class associated with a particular symbol can be changed by using
|
|
<tt>setf</tt> with <tt>find-class</tt>. The results are undefined if
|
|
the user attempts to change the class associated with a symbol that is
|
|
defined as a type specifier in chapter <A HREF="node44.html#DTSPEC">4</A>.
|
|
See section <A HREF="node273.html#IntegratingTypesandClassesSECTION">28.1.4</A>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>find-method <i>generic-function</i> <i>method-qualifiers</i> <i>specializers</i> &optional <i>errorp</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<pre>
|
|
find-method (<i>generic-function</i> standard-generic-function)
|
|
<i>method-qualifiers</i> <i>specializers</i> &optional <i>errorp</i>
|
|
</pre>
|
|
<P>The generic function <tt>find-method</tt> takes a generic function and
|
|
returns the method object that agrees on method qualifiers and
|
|
parameter specializers with the <i>method-qualifiers</i> and <i>specializers</i> arguments of <tt>find-method</tt>.
|
|
See section <A HREF="node280.html#AgreementonParameterSpecializersandQualifiersSECTION">28.1.6.3</A> for a
|
|
definition of agreement in this context.
|
|
<P>
|
|
The <i>generic-function</i> argument is a generic function.
|
|
<P>
|
|
The <i>method-qualifiers</i> argument is a list of the
|
|
method qualifiers for the method. The order of the method qualifiers
|
|
is significant.
|
|
<P>
|
|
The <i>specializers</i> argument is a list of the parameter
|
|
specializers for the method. It must correspond in length to
|
|
the number of required arguments of the generic function, or
|
|
an error is signaled. This means that to obtain the
|
|
default method on a given generic function, a list whose
|
|
elements are the class named <tt>t</tt> must be given.
|
|
<P>
|
|
If there is no such method and the <i>errorp</i> argument is
|
|
not supplied or is non-<tt>nil</tt>, <tt>find-method</tt> signals an error.
|
|
If there is no such method and the <i>errorp</i> argument is
|
|
<tt>nil</tt>, <tt>find-method</tt> returns <tt>nil</tt>. The default value of
|
|
<i>errorp</i> is <tt>t</tt>.
|
|
<P>
|
|
The result of <tt>find-method</tt> is the method object with the given
|
|
method qualifiers and parameter specializers.
|
|
<P>
|
|
See section <A HREF="node280.html#AgreementonParameterSpecializersandQualifiersSECTION">28.1.6.3</A>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>function-keywords <i>method</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>function-keywords (<i>method</i> standard-method)</tt><P>The generic function <tt>function-keywords</tt> is used to return the keyword
|
|
parameter specifiers for a given method.
|
|
<P>
|
|
The <i>method</i> argument is a method object.
|
|
<P>
|
|
The generic function <tt>function-keywords</tt> returns two values:
|
|
a list of the explicitly named keywords and a boolean that states whether
|
|
<tt>&allow-other-keys</tt> had been specified in the method definition.
|
|
<P>
|
|
<BR><b>[Special Form]</b><BR>
|
|
<pre>
|
|
generic-flet ({(<i>function-name</i> <i>lambda-list</i>
|
|
<b>[[</b>?<i>option</i> | {<i>method-description</i>}* <b>]]</b>)}*)
|
|
{<i>form</i>}*
|
|
</pre>
|
|
<P>The <tt>generic-flet</tt> special form is analogous to the
|
|
<tt>flet</tt> special form. It produces new generic functions and
|
|
establishes new lexical function definition bindings. Each generic
|
|
function is created with the set of methods specified by its method
|
|
descriptions.
|
|
<P>
|
|
The special form <tt>generic-flet</tt> is used to define generic functions whose
|
|
names are meaningful only locally and to execute a series of forms
|
|
with these function definition bindings. Any number of such local
|
|
generic functions may be defined.
|
|
<P>
|
|
The names of functions defined by <tt>generic-flet</tt> have lexical
|
|
scope; they retain their local definitions only within the body of the
|
|
<tt>generic-flet</tt>. Any references within the body of the
|
|
<tt>generic-flet</tt> to functions whose names are the same as those defined
|
|
within the <tt>generic-flet</tt> are thus references to the local
|
|
functions instead of to any global functions of the same names. The
|
|
scope of these generic function definition bindings, however, includes only
|
|
the body of <tt>generic-flet</tt>, not the definitions themselves.
|
|
Within the method bodies, local function names that match those
|
|
being defined refer to global functions defined outside the
|
|
<tt>generic-flet</tt>. It is thus not possible to define recursive functions
|
|
with <tt>generic-flet</tt>.
|
|
<P>
|
|
The <i>function-name</i>, <i>lambda-list</i>, <i>option</i>, <i>method-qualifier</i>, and <i>specialized-lambda-list</i> arguments are
|
|
the same as for <tt>defgeneric</tt>.
|
|
<P>
|
|
A <tt>generic-flet</tt> local method definition is identical in form to the
|
|
method definition part of a <tt>defmethod</tt>.
|
|
<P>
|
|
The body of each method is enclosed in an implicit block. If <i>function-name</i> is a symbol, this block bears the same name as
|
|
the generic function. If <i>function-name</i> is a list of the
|
|
form <tt>(setf <i>symbol</i>)</tt>, the name of the block is <i>symbol</i>.
|
|
<P>
|
|
The result returned by <tt>generic-flet</tt> is the value or values
|
|
returned by the last form executed. If no forms are specified,
|
|
<tt>generic-flet</tt> returns <tt>nil</tt>.
|
|
<P>
|
|
See <tt>generic-labels</tt>, <tt>defmethod</tt>, <tt>defgeneric</tt>, and <tt>generic-function</tt>.
|
|
<P>
|
|
<BR><b>[Macro]</b><BR>
|
|
<pre>
|
|
generic-function <i>lambda-list</i> <b>[[</b>?<i>option</i> | {<i>method-description</i>}*<b>]]</b>
|
|
|
|
<i>option</i> ::= (:argument-precedence-order {<i>parameter-name</i>}+)
|
|
| (declare {<i>declaration</i>}+)
|
|
| (:documentation <i>string</i>)
|
|
| (:method-combination <i>symbol</i> {<i>arg</i>}*)
|
|
| (:generic-function-class <i>class-name</i>)
|
|
| (:method-class <i>class-name</i>)
|
|
<i>method-description</i> ::= (:method {<i>method-qualifier</i>}*
|
|
<i>specialized-lambda-list</i>
|
|
{<i>declaration</i> | <i>documentation</i>}*
|
|
{<i>form</i>}*)
|
|
</pre>
|
|
The <tt>generic-function</tt> macro creates an anonymous generic
|
|
function. The generic function is created with the set of methods
|
|
specified by its method descriptions.
|
|
<P>
|
|
The <i>option</i>, <i>method-qualifier</i>, and <i>specialized-lambda-list</i> arguments are the same as for
|
|
<tt>defgeneric</tt>.
|
|
<P>
|
|
The generic function object is returned as the result.
|
|
<P>
|
|
If no method descriptions are specified, an anonymous generic function with no
|
|
methods is created.
|
|
<P>
|
|
See <tt>defgeneric</tt>, <tt>generic-flet</tt>, <tt>generic-labels</tt>, and <tt>defmethod</tt>.
|
|
<P>
|
|
<BR><b>[Special Form]</b><BR>
|
|
<pre>
|
|
generic-labels ((<i>function-name</i> <i>lambda-list</i>
|
|
<b>[[</b>?<i>option</i> | {<i>method-description</i>}*<b>]]</b>)}*)
|
|
{<i>form</i>}*
|
|
</pre>
|
|
<P>The <tt>generic-labels</tt> special form is analogous to the
|
|
<tt>labels</tt> special form. It produces new generic functions and
|
|
establishes new lexical function definition bindings. Each generic
|
|
function is created with the set of methods specified by its method
|
|
descriptions.
|
|
<P>
|
|
The special form <tt>generic-labels</tt> is used to define generic functions
|
|
whose names are meaningful only locally and to execute a series of
|
|
forms with these function definition bindings. Any number of
|
|
such local generic functions may be defined.
|
|
<P>
|
|
The names of functions defined by <tt>generic-labels</tt> have lexical
|
|
scope; they retain their local definitions only within the body of the
|
|
<tt>generic-labels</tt> construct. Any references within the body of the
|
|
<tt>generic-labels</tt> construct to functions whose names are the same
|
|
as those defined within the <tt>generic-labels</tt> form are thus
|
|
references to the local functions instead of to any global functions
|
|
of the same names. The scope of these generic function definition bindings
|
|
includes the method bodies themselves as well as the body of the
|
|
<tt>generic-labels</tt> construct.
|
|
<P>
|
|
The <i>function-name</i>, <i>lambda-list</i>, <i>option</i>, <i>method-qualifier</i>, and <i>specialized-lambda-list</i> arguments are
|
|
the same as for <tt>defgeneric</tt>.
|
|
<P>
|
|
A <tt>generic-labels</tt> local method definition is identical in form to the
|
|
method definition part of a <tt>defmethod</tt>.
|
|
<P>
|
|
The body of each method is enclosed in an implicit block. If <i>function-name</i> is a symbol, this block bears the same name as
|
|
the generic function. If <i>function-name</i> is a list of the
|
|
form <tt>(setf <i>symbol</i>)</tt>, the name of the block is <i>symbol</i>.
|
|
<P>
|
|
The result returned by <tt>generic-labels</tt> is the value or values
|
|
returned by the last form executed. If no forms are specified,
|
|
<tt>generic-labels</tt> returns <tt>nil</tt>.
|
|
<P>
|
|
See <tt>generic-flet</tt>, <tt>defmethod</tt>, <tt>defgeneric</tt>, <tt>generic-function</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>initialize-instance <i>instance</i> &rest <i>initargs</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>initialize-instance (<i>instance</i> standard-object) &rest <i>initargs</i></tt>
|
|
<P>The generic function <tt>initialize-instance</tt> is called by
|
|
<tt>make-instance</tt> to initialize a newly created instance. The generic
|
|
function <tt>initialize-instance</tt> is called with the new instance and
|
|
the defaulted initialization arguments.
|
|
<P>
|
|
The system-supplied primary method on <tt>initialize-instance</tt>
|
|
initializes the slots of the instance with values according to the
|
|
initialization arguments and the <tt>:initform</tt> forms of the slots.
|
|
It does this by calling the generic function <tt>shared-initialize</tt>
|
|
with the following arguments: the instance, <tt>t</tt> (this indicates
|
|
that all slots for which no initialization arguments are provided
|
|
should be initialized according to their <tt>:initform</tt> forms) and
|
|
the defaulted initialization arguments.
|
|
<P>
|
|
The <i>instance</i> argument is the object to be initialized.
|
|
<P>
|
|
The <i>initargs</i> argument consists of alternating initialization
|
|
argument names and values.
|
|
<P>
|
|
The modified instance is returned as the result.
|
|
<P>
|
|
Programmers can define methods for <tt>initialize-instance</tt> to
|
|
specify actions to be taken when an instance is initialized. If only
|
|
<tt>:after</tt> methods are defined, they will be run after the
|
|
system-supplied primary method for initialization and therefore will
|
|
not interfere with the default behavior of <tt>initialize-instance</tt>.
|
|
<P>
|
|
See sections <A HREF="node292.html#ObjectCreationandInitializationSECTION">28.1.9</A>,
|
|
<A HREF="node296.html#RulesforInitializationArgumentsSECTION">28.1.9.4</A>, and
|
|
<A HREF="node294.html#DeclaringtheValidityofInitializationArgumentsSECTION">28.1.9.2</A> as well as
|
|
<tt>shared-initialize</tt>,
|
|
<tt>make-instance</tt>,
|
|
<tt>slot-boundp</tt>,
|
|
and <tt>slot-makunbound</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>invalid-method-error <i>method</i> <i>format-string</i> &rest <i>args</i></tt><P>The function <tt>invalid-method-error</tt> is used to signal an error
|
|
when there is an applicable method whose qualifiers are not valid for
|
|
the method combination type. The error message is constructed by
|
|
using a <tt>format</tt> string and any arguments to it. Because an
|
|
implementation may need to add additional contextual information to
|
|
the error message, <tt>invalid-method-error</tt> should be called only
|
|
within the dynamic extent of a method combination function.
|
|
<P>
|
|
The function <tt>invalid-method-error</tt> is called automatically when a
|
|
method fails to satisfy every qualifier pattern and predicate in a
|
|
<tt>define-method-combination</tt> form.
|
|
A method combination function
|
|
that imposes additional restrictions should call
|
|
<tt>invalid-method-error</tt> explicitly if it encounters a method it cannot
|
|
accept.
|
|
<P>
|
|
The <i>method</i> argument is the invalid method object.
|
|
<P>
|
|
The <i>format-string</i> argument is a control string that can be
|
|
given to <tt>format</tt>, and <i>args</i> are any arguments required by
|
|
that string.
|
|
<P>
|
|
Whether <tt>invalid-method-error</tt> returns to its caller or exits via
|
|
<tt>throw</tt> is implementation-dependent.
|
|
<P>
|
|
See <tt>define-method-combination</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>make-instance <i>class</i> &rest <i>initargs</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>make-instance (<i>class</i> standard-class) &rest <i>initargs</i> <BR></tt><tt>make-instance (<i>class</i> symbol) &rest <i>initargs</i></tt><P>The generic function <tt>make-instance</tt> creates a new
|
|
instance of the given class.
|
|
<P>
|
|
The generic function <tt>make-instance</tt> may be used as described in
|
|
section <A HREF="node292.html#ObjectCreationandInitializationSECTION">28.1.9</A>.
|
|
<P>
|
|
The <i>class</i> argument is a class object or a symbol that
|
|
names a class. The remaining arguments form a list of alternating
|
|
initialization argument names and values.
|
|
<P>
|
|
If the second of the preceding methods is selected, that method invokes
|
|
<tt>make-instance</tt> on the arguments <tt>(find-class <i>class</i>)</tt> and
|
|
<i>initargs</i>.
|
|
<P>
|
|
The initialization arguments are checked within <tt>make-instance</tt>
|
|
(see section <A HREF="node292.html#ObjectCreationandInitializationSECTION">28.1.9</A>).
|
|
<P>
|
|
The new instance is returned.
|
|
<P>
|
|
The meta-object protocol can be used to define new methods on
|
|
<tt>make-instance</tt> to replace the object-creation protocol.
|
|
<P>
|
|
See section <A HREF="node292.html#ObjectCreationandInitializationSECTION">28.1.9</A> as well as
|
|
<tt>defclass</tt>, <tt>initialize-instance</tt>, and <tt>class-of</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>make-instances-obsolete <i>class</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>make-instances-obsolete (<i>class</i> standard-class) <BR></tt><tt>make-instances-obsolete (<i>class</i> symbol)</tt><P>The generic function <tt>make-instances-obsolete</tt> is invoked
|
|
automatically by the system when <tt>defclass</tt> has been used to
|
|
redefine an existing standard class and the set of local slots accessible in an
|
|
instance is changed or the order of slots in storage is changed. It
|
|
can also be explicitly invoked by the user.
|
|
<P>
|
|
The function <tt>make-instances-obsolete</tt> has the effect of
|
|
initiating the process of updating the instances of the
|
|
class. During updating, the generic function
|
|
<tt>update-instance-for-redefined-class</tt> will be invoked.
|
|
<P>
|
|
The <i>class</i> argument is a class object symbol that names
|
|
the class whose instances are to be made obsolete.
|
|
<P>
|
|
If the second of the preceding methods is selected, that method invokes
|
|
<tt>make-instances-obsolete</tt> on <tt>(find-class <i>class</i>)</tt>.
|
|
<P>
|
|
The modified class is returned. The result of <tt>make-instances-obsolete</tt>
|
|
is <tt>eq</tt> to the <i>class</i> argument supplied to the first of the preceding
|
|
methods.
|
|
<P>
|
|
See section <A HREF="node300.html#RedefiningClassesSECTION">28.1.10</A> as well as
|
|
<tt>update-instance-for-redefined-class</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>method-combination-error <i>format-string</i> &rest <i>args</i></tt><P>The function <tt>method-combination-error</tt> is used to signal an error
|
|
in method combination. The error message is constructed by using a
|
|
<tt>format</tt> string and any arguments to it. Because an implementation may
|
|
need to add additional contextual information to the error message,
|
|
<tt>method-combination-error</tt> should be called only within the
|
|
dynamic extent of a method combination function.
|
|
<P>
|
|
The <i>format-string</i> argument is a control string that can be
|
|
given to <tt>format</tt>, and <i>args</i> are any arguments required by
|
|
that string.
|
|
<P>
|
|
Whether <tt>method-combination-error</tt> returns to its caller or exits
|
|
via <tt>throw</tt> is implementation-dependent.
|
|
<P>
|
|
See <tt>define-method-combination</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>method-qualifiers <i>method</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>method-qualifiers (<i>method</i> standard-method)</tt><P>The generic function <tt>method-qualifiers</tt> returns a list of the
|
|
qualifiers of the given method.
|
|
<P>
|
|
The <i>method</i> argument is a method object.
|
|
<P>
|
|
A list of the qualifiers of the given method is returned.
|
|
<P>
|
|
Example:
|
|
<P><pre>
|
|
(setq methods (remove-duplicates methods
|
|
:from-end t
|
|
:key #'method-qualifiers
|
|
:test #'equal))
|
|
</pre><P>
|
|
<P>
|
|
See <tt>define-method-combination</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>next-method-p</tt><P>The locally defined function <tt>next-method-p</tt> can be used within
|
|
the body of a method defined by a method-defining form to determine
|
|
whether a next method exists.
|
|
<P>
|
|
The function <tt>next-method-p</tt> takes no arguments.
|
|
<P>
|
|
The function <tt>next-method-p</tt> returns true or false.
|
|
<P>
|
|
Like <tt>call-next-method</tt>, the function <tt>next-method-p</tt> has
|
|
lexical scope (for it
|
|
is defined only within the body of a method defined by a method-defining form)
|
|
and indefinite extent.
|
|
<P>
|
|
See <tt>call-next-method</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>no-applicable-method <i>generic-function</i> &rest <i>function-arguments</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>no-applicable-method (<i>generic-function</i> t) &rest <i>function-arguments</i></tt><P>The generic function <tt>no-applicable-method</tt> is called when a
|
|
generic function of the class <tt>standard-generic-function</tt> is invoked
|
|
and no method on that generic function is applicable.
|
|
The default method signals an error.
|
|
<P>
|
|
The generic function <tt>no-applicable-method</tt> is not intended to be called
|
|
by programmers. Programmers may write methods for it.
|
|
<P>
|
|
The <i>generic-function</i> argument of <tt>no-applicable-method</tt> is the
|
|
generic function object on which no applicable method was found.
|
|
<P>
|
|
The <i>function-arguments</i> argument is a list of the arguments to that
|
|
generic function.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>no-next-method <i>generic-function</i> <i>method</i> &rest <i>args</i></tt> <BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<pre>
|
|
no-next-method (<i>generic-function</i> standard-generic-function)
|
|
(<i>method</i> standard-method) &rest <i>args</i>
|
|
</pre>
|
|
<P>The generic function <tt>no-next-method</tt> is called by
|
|
<tt>call-next-method</tt> when there is no next method. The system-supplied
|
|
method on <tt>no-next-method</tt> signals an error.
|
|
<P>
|
|
The generic function <tt>no-next-method</tt> is not intended to be called
|
|
by programmers. Programmers may write methods for it.
|
|
<P>
|
|
The <i>generic-function</i> argument is the generic function object
|
|
to which the method that is the second argument belongs.
|
|
<P>
|
|
The <i>method</i> argument is the method that contains the call to
|
|
<tt>call-next-method</tt> for which there is no next method.
|
|
<P>
|
|
The <i>args</i> argument is a list of the arguments to
|
|
<tt>call-next-method</tt>.
|
|
<P>
|
|
See <tt>call-next-method</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>print-object <i>object</i> <i>stream</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>print-object (<i>object</i> standard-object) <i>stream</i></tt><P>The generic function <tt>print-object</tt> writes the printed
|
|
representation of an object to a stream. The function
|
|
<tt>print-object</tt> is called by the print system; it should not be called
|
|
by the user.
|
|
<P>
|
|
|
|
<P>
|
|
Each implementation must provide a method on the class
|
|
<tt>standard-object</tt> and methods on enough other classes so as to ensure
|
|
that there is always an applicable method. Implementations are free
|
|
to add methods for other classes. Users can write methods for
|
|
<tt>print-object</tt> for their own classes if they do not wish to inherit an
|
|
implementation-supplied method.
|
|
<P>
|
|
The first argument is any Lisp object. The second argument is a
|
|
stream; it cannot be <tt>t</tt> or <tt>nil</tt>.
|
|
<P>
|
|
The function <tt>print-object</tt> returns its first argument, the object.
|
|
<P>
|
|
Methods on <tt>print-object</tt> must obey the print control special
|
|
variables named <tt>*print-<i>xxx</i>*</tt> for various <i>xxx</i>. The
|
|
specific details are the following:
|
|
<P>
|
|
<UL><LI>
|
|
Each method must implement <tt>*print-escape*</tt>.
|
|
<P>
|
|
<LI>
|
|
The <tt>*print-pretty*</tt> control variable can be ignored
|
|
by most methods other than the one for lists.
|
|
<P>
|
|
<LI>
|
|
The <tt>*print-circle*</tt> control variable is handled by the printer
|
|
and can be ignored by methods.
|
|
<P>
|
|
<LI>
|
|
The printer takes care of <tt>*print-level*</tt> automatically, provided that
|
|
each method handles exactly one level of structure and
|
|
calls <tt>write</tt> (or an equivalent function) recursively if
|
|
there are more structural levels. The printer's decision
|
|
of whether an object has components (and therefore should
|
|
not be printed when the printing depth is not less than
|
|
<tt>*print-level*</tt>) is implementation-dependent. In some
|
|
implementations its <tt>print-object</tt> method is not called; in
|
|
others the method is called, and the determination that the
|
|
object has components is based on what it tries to write
|
|
to the stream.
|
|
<P>
|
|
<LI>
|
|
Methods that produce output of indefinite length must obey
|
|
<tt>*print-length*</tt>, but most methods other than the one for lists can
|
|
ignore it.
|
|
<P>
|
|
<LI>
|
|
The <tt>*print-base*</tt>, <tt>*print-radix*</tt>, <tt>*print-case*</tt>,
|
|
<tt>*print-gensym*</tt>, and <tt>*print-array*</tt> control variables apply
|
|
to specific types of objects and are handled by the methods for those
|
|
objects.
|
|
<P>
|
|
<LI> X3J13 voted in June 1989 (DATA-IO) <A NAME=35028> </A> to add the following point.
|
|
All methods for <tt>print-object</tt> must obey <tt>*print-readably*</tt>,
|
|
which takes precedence over all other printer control variables. This
|
|
includes both user-defined methods and implementation-defined methods.
|
|
</UL>
|
|
<P>
|
|
If these rules are not obeyed, the results are undefined.
|
|
<P>
|
|
In general, the printer and the <tt>print-object</tt> methods should not
|
|
rebind the print control variables as they operate recursively through the
|
|
structure, but this is implementation-dependent.
|
|
<P>
|
|
In some implementations the stream argument passed to a
|
|
<tt>print-object</tt> method is not the original stream but is an
|
|
intermediate stream that implements part of the printer. Methods
|
|
should therefore not depend on the identity of this stream.
|
|
<P>
|
|
All of the existing printing functions (<tt>write</tt>, <tt>prin1</tt>,
|
|
<tt>print</tt>, <tt>princ</tt>, <tt>pprint</tt>, <tt>write-to-string</tt>,
|
|
<tt>prin1-to-string</tt>, <tt>princ-to-string</tt>, the <tt>~S</tt> and
|
|
<tt>~A format</tt> operations, and the <tt>~B</tt>, <tt>~D</tt>,
|
|
<tt>~E</tt>, <tt>~F</tt>, <tt>~G</tt>, <tt>~$</tt>,
|
|
<tt>~O</tt>, <tt>~R</tt>, and <tt>~X format</tt> operations when they
|
|
encounter a non-numeric value) are required to be changed to go
|
|
through the <tt>print-object</tt> generic function. Each implementation is
|
|
required to replace its former implementation of printing with one or
|
|
more <tt>print-object</tt> methods. Exactly which classes have methods for
|
|
<tt>print-object</tt> is not specified; it would be valid for an implementation
|
|
to have one default method that is inherited by all system-defined
|
|
classes.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>reinitialize-instance <i>instance</i> &rest <i>initargs</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>reinitialize-instance (<i>instance</i> standard-object) &rest <i>initargs</i></tt><P>The generic function <tt>reinitialize-instance</tt> can be used to change
|
|
the values of local slots according to initialization arguments. This
|
|
generic function is called by the Meta-Object Protocol. It can also be
|
|
called by users.
|
|
<P>
|
|
The system-supplied primary method for <tt>reinitialize-instance</tt>
|
|
checks the validity of initialization arguments and signals an error if
|
|
an initialization argument is supplied that is not declared valid.
|
|
The method then calls the generic function <tt>shared-initialize</tt>
|
|
with the following arguments: the instance, <tt>nil</tt> (which means no slots
|
|
should be initialized according to their <tt>:initform</tt> forms) and the
|
|
initialization arguments it received.
|
|
<P>
|
|
The <i>instance</i> argument is the object to be initialized.
|
|
<P>
|
|
The <i>initargs</i> argument consists of alternating initialization
|
|
argument names and values.
|
|
<P>
|
|
The modified instance is returned as the result.
|
|
<P>
|
|
Initialization arguments are declared valid by using the
|
|
<tt>:initarg</tt> option to <tt>defclass</tt>, or by defining methods for
|
|
<tt>reinitialize-instance</tt> or <tt>shared-initialize</tt>. The keyword name
|
|
of each keyword parameter specifier in the lambda-list of any method
|
|
defined on <tt>reinitialize-instance</tt> or <tt>shared-initialize</tt> is
|
|
declared a valid initialization argument name for all classes for
|
|
which that method is applicable.
|
|
<P>
|
|
See sections <A HREF="node309.html#ReinitializinganInstanceSECTION">28.1.12</A>,
|
|
<A HREF="node296.html#RulesforInitializationArgumentsSECTION">28.1.9.4</A>,
|
|
<A HREF="node294.html#DeclaringtheValidityofInitializationArgumentsSECTION">28.1.9.2</A> as well as
|
|
<tt>initialize-instance</tt>, <tt>slot-boundp</tt>,
|
|
<tt>update-instance-for-redefined-class</tt>,
|
|
<tt>update-instance-for-different-class</tt>,
|
|
<tt>slot-makunbound</tt>, and <tt>shared-initialize</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>remove-method <i>generic-function</i> <i>method</i></tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>remove-method (<i>generic-function</i> standard-generic-function) <i>method</i></tt><P>The generic function <tt>remove-method</tt> removes a method from a
|
|
generic function. It destructively modifies the specified generic
|
|
function and returns the modified generic function as its result.
|
|
<P>
|
|
The <i>generic-function</i> argument is a generic function
|
|
object.
|
|
<P>
|
|
The <i>method</i> argument is a method object. The function
|
|
<tt>remove-method</tt> does not signal an error if the method is not one of the
|
|
methods on the generic function.
|
|
<P>
|
|
The modified generic function is returned. The result of <tt>remove-method</tt>
|
|
is <tt>eq</tt> to the <i>generic-function</i> argument.
|
|
<P>
|
|
See <tt>find-method</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>shared-initialize <i>instance</i> <i>slot-names</i> &rest <i>initargs</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<pre>
|
|
shared-initialize (<i>instance</i> standard-object)
|
|
<i>slot-names</i> &rest <i>initargs</i>
|
|
</pre>
|
|
<P>The generic function <tt>shared-initialize</tt> is used to fill the slots
|
|
of an instance using initialization arguments and <tt>:initform</tt>
|
|
forms. It is called when an instance is created, when an instance is
|
|
re-initialized, when an instance is updated to conform to a redefined
|
|
class, and when an instance is updated to conform to a different
|
|
class. The generic function <tt>shared-initialize</tt> is called by the
|
|
system-supplied primary method for <tt>initialize-instance</tt>,
|
|
<tt>reinitialize-instance</tt>,
|
|
<tt>update-instance-for-redefined-class</tt>, and
|
|
<tt>update-instance-for-different-class</tt>.
|
|
<P>
|
|
The generic function <tt>shared-initialize</tt> takes the following
|
|
arguments: the instance to be initialized, a specification of a set of
|
|
names of slots accessible in that instance, and any number of initialization
|
|
arguments. The arguments after the first two must form an initialization
|
|
argument list. The system-supplied primary method on
|
|
<tt>shared-initialize</tt> initializes the slots with values according to the
|
|
initialization arguments and specified <tt>:initform</tt> forms. The
|
|
second argument indicates which slots should be initialized according
|
|
to their <tt>:initform</tt> forms if no initialization arguments are
|
|
provided for those slots.
|
|
<P>
|
|
The system-supplied primary method behaves as follows, regardless of
|
|
whether the slots are local or shared:
|
|
<P>
|
|
<UL><LI> If an initialization argument in the
|
|
initialization argument list specifies a value for that slot, that
|
|
value is stored into the slot, even if a value has
|
|
already been stored in the slot before the method is run.
|
|
<P>
|
|
<LI> Any slots indicated by the second argument that are still
|
|
unbound at this point are initialized according to their
|
|
<tt>:initform</tt> forms. For any such slot that has an <tt>:initform</tt> form,
|
|
that form is evaluated in the lexical environment of its defining
|
|
<tt>defclass</tt> form and the result is stored into the slot. For example, if
|
|
a <tt>:before</tt> method stores a value in the slot, the <tt>:initform</tt>
|
|
form will not be used to supply a value for the slot.
|
|
<P>
|
|
<LI> The rules mentioned in section <A HREF="node296.html#RulesforInitializationArgumentsSECTION">28.1.9.4</A> are obeyed.
|
|
<P>
|
|
</UL>
|
|
<P>
|
|
The <i>instance</i> argument is the object to be initialized.
|
|
<P>
|
|
The <i>slot-names</i> argument specifies the slots that are to be
|
|
initialized according to their <tt>:initform</tt> forms if no
|
|
initialization arguments apply. It is supplied in one of three forms
|
|
as follows:
|
|
<P>
|
|
<UL><LI> It can be a list of slot names, which specifies
|
|
the set of those slot names.
|
|
<P>
|
|
<LI> It can be <tt>nil</tt>, which specifies the empty set of
|
|
slot names.
|
|
<P>
|
|
<LI> It can be the symbol <tt>t</tt>, which specifies the set of
|
|
all of the slots.
|
|
<P>
|
|
</UL>
|
|
<P>
|
|
The <i>initargs</i> argument consists of alternating initialization
|
|
argument names and values.
|
|
<P>
|
|
The modified instance is returned as the result.
|
|
<P>
|
|
Initialization arguments are declared valid by using the
|
|
<tt>:initarg</tt> option to <tt>defclass</tt>, or by defining methods for
|
|
<tt>shared-initialize</tt>. The keyword name of each keyword parameter
|
|
specifier in the lambda-list of any method defined on
|
|
<tt>shared-initialize</tt> is declared a valid initialization argument
|
|
name for all classes for which that method is applicable.
|
|
<P>
|
|
Implementations are permitted to optimize <tt>:initform</tt> forms that
|
|
neither produce nor depend on side effects by evaluating these forms
|
|
and storing them into slots before running any
|
|
<tt>initialize-instance</tt> methods, rather than by handling them in the
|
|
primary <tt>initialize-instance</tt> method. (This optimization might
|
|
be implemented by having the <tt>allocate-instance</tt> method copy a
|
|
prototype instance.)
|
|
<P>
|
|
Implementations are permitted to optimize default initial value forms
|
|
for initialization arguments associated with slots by not actually
|
|
creating the complete initialization argument list when the only method
|
|
that would receive the complete list is the method on
|
|
<tt>standard-object</tt>. In this case, default initial value forms can be
|
|
treated like <tt>:initform</tt> forms. This optimization has no visible
|
|
effects other than a performance improvement.
|
|
<P>
|
|
See sections <A HREF="node292.html#ObjectCreationandInitializationSECTION">28.1.9</A>,
|
|
<A HREF="node296.html#RulesforInitializationArgumentsSECTION">28.1.9.4</A>,
|
|
<A HREF="node294.html#DeclaringtheValidityofInitializationArgumentsSECTION">28.1.9.2</A> as well as
|
|
<tt>initialize-instance</tt>,
|
|
<tt>reinitialize-instance</tt>,
|
|
<tt>update-instance-for-redefined-class</tt>,
|
|
<tt>update-instance-for-different-class</tt>,
|
|
<tt>slot-boundp</tt>,
|
|
and <tt>slot-makunbound</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>slot-boundp <i>instance</i> <i>slot-name</i></tt><P>The function <tt>slot-boundp</tt> tests whether a specific slot in an
|
|
instance is bound.
|
|
<P>
|
|
The arguments are the instance and the name of the slot.
|
|
<P>
|
|
The function <tt>slot-boundp</tt> returns true or false.
|
|
<P>
|
|
This function allows for writing <tt>:after</tt>
|
|
methods on <tt>initialize-instance</tt> in order to initialize only
|
|
those slots that have not already been bound.
|
|
<P>
|
|
If no slot of the given name exists in the instance, <tt>slot-missing</tt>
|
|
is called as follows:
|
|
<P><pre>
|
|
(slot-missing (class-of <i>instance</i>)
|
|
<i>instance</i>
|
|
<i>slot-name</i>
|
|
'slot-boundp)
|
|
</pre><P>
|
|
<P>
|
|
The function <tt>slot-boundp</tt> is implemented using
|
|
<tt>slot-boundp-using-class</tt>.
|
|
See <tt>slot-missing</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>slot-exists-p <i>object</i> <i>slot-name</i></tt><P>The function <tt>slot-exists-p</tt> tests whether the specified object has
|
|
a slot of the given name.
|
|
<P>
|
|
The <i>object</i> argument is any object. The <i>slot-name</i> argument
|
|
is a symbol.
|
|
<P>
|
|
The function <tt>slot-exists-p</tt> returns true or false.
|
|
<P>
|
|
The function <tt>slot-exists-p</tt> is implemented using
|
|
<tt>slot-exists-p-using-class</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>slot-makunbound <i>instance</i> <i>slot-name</i></tt><P>The function <tt>slot-makunbound</tt> restores a slot in an instance to
|
|
the unbound state.
|
|
<P>
|
|
The arguments to <tt>slot-makunbound</tt> are the instance and the name of
|
|
the slot.
|
|
<P>
|
|
The instance is returned as the result.
|
|
<P>
|
|
If no slot of the given name exists in the instance, <tt>slot-missing</tt>
|
|
is called as follows:
|
|
<P><pre>
|
|
(slot-missing (class-of <i>instance</i>)
|
|
<i>instance</i>
|
|
<i>slot-name</i>
|
|
'slot-makunbound)
|
|
</pre><P>
|
|
<P>
|
|
The function <tt>slot-makunbound</tt> is implemented using
|
|
<tt>slot-makunbound-using-class</tt>.
|
|
See <tt>slot-missing</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>slot-missing <i>class</i> <i>object</i> <i>slot-name</i> <i>operation</i> &optional <i>new-value</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>slot-missing (<i>class</i> t) <i>object</i> <i>slot-name</i> <i>operation</i> &optional <i>new-value</i></tt><P>The generic function <tt>slot-missing</tt> is invoked when an attempt is
|
|
made to access a slot in an object whose metaclass is
|
|
<tt>standard-class</tt> and the name of the slot provided is not a name of a
|
|
slot in that class.
|
|
The default method signals an error.
|
|
<P>
|
|
The generic function <tt>slot-missing</tt> is not intended to be called by
|
|
programmers. Programmers may write methods for it.
|
|
<P>
|
|
The required arguments to <tt>slot-missing</tt> are the class of the object
|
|
that is being accessed, the object, the slot name, and a symbol that
|
|
indicates the operation that caused <tt>slot-missing</tt> to be invoked.
|
|
The optional argument to <tt>slot-missing</tt> is used when the operation
|
|
is attempting to set the value of the slot.
|
|
<P>
|
|
If a method written for <tt>slot-missing</tt> returns values, these
|
|
values get returned as the values of the original function invocation.
|
|
<P>
|
|
The generic function <tt>slot-missing</tt> may be called during
|
|
evaluation of <tt>slot-value</tt>, <tt>(setf slot-value)</tt>,
|
|
<tt>slot-boundp</tt>, and <tt>slot-makunbound</tt>. For each
|
|
of these operations the corresponding symbol for the <i>operation</i>
|
|
argument is <tt>slot-value</tt>, <tt>setf</tt>, <tt>slot-boundp</tt>, and
|
|
<tt>slot-makunbound</tt>, respectively.
|
|
<P>
|
|
The set of arguments (including the class of the instance) facilitates
|
|
defining methods on the metaclass for <tt>slot-missing</tt>.
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>slot-unbound <i>class</i> <i>instance</i> <i>slot-name</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<tt>slot-unbound (<i>class</i> t) <i>instance</i> <i>slot-name</i></tt><P>The generic function <tt>slot-unbound</tt> is called when an
|
|
unbound slot is read in an instance whose metaclass is
|
|
<tt>standard-class</tt>.
|
|
The default method signals an error.
|
|
<P>
|
|
The generic function <tt>slot-unbound</tt> is not intended to be called
|
|
by programmers. Programmers may write methods for it.
|
|
The function <tt>slot-unbound</tt> is called only by the function
|
|
<tt>slot-value-using-class</tt> and thus indirectly by <tt>slot-value</tt>.
|
|
<P>
|
|
The arguments to <tt>slot-unbound</tt> are the class of the instance
|
|
whose slot was accessed, the instance itself, and the name of the
|
|
slot.
|
|
<P>
|
|
If a method written for <tt>slot-unbound</tt> returns values, these
|
|
values get returned as the values of the original function invocation.
|
|
<P>
|
|
An unbound slot may occur if no <tt>:initform</tt> form was
|
|
specified for the slot and the slot value has not been set, or if
|
|
<tt>slot-makunbound</tt> has been called on the slot.
|
|
<P>
|
|
See <tt>slot-makunbound</tt>.
|
|
<P>
|
|
<BR><b>[Function]</b><BR>
|
|
<tt>slot-value <i>object</i> <i>slot-name</i></tt><P>The function <tt>slot-value</tt> returns the value contained in the slot
|
|
<i>slot-name</i> of the given object. If there is no slot with that
|
|
name, <tt>slot-missing</tt> is called. If the slot is unbound,
|
|
<tt>slot-unbound</tt> is called.
|
|
<P>
|
|
The macro <tt>setf</tt> can be used with <tt>slot-value</tt> to change the value
|
|
of a slot.
|
|
<P>
|
|
The arguments are the object and the name of the given slot.
|
|
<P>
|
|
The result is the value contained in the given slot.
|
|
<P>
|
|
If an attempt is made to read a slot and no slot of the given name
|
|
exists in the instance, <tt>slot-missing</tt> is called as follows:
|
|
<P><pre>
|
|
(slot-missing (class-of <i>instance</i>)
|
|
<i>instance</i>
|
|
<i>slot-name</i>
|
|
'slot-value)
|
|
</pre><P>
|
|
<P>
|
|
If an attempt is made to write a slot and no slot of the given name
|
|
exists in the instance, <tt>slot-missing</tt> is called as follows:
|
|
<P><pre>
|
|
(slot-missing (class-of <i>instance</i>)
|
|
<i>instance</i>
|
|
<i>slot-name</i>
|
|
'setf
|
|
<i>new-value</i>)
|
|
</pre><P>
|
|
<P>
|
|
The function <tt>slot-value</tt> is implemented using
|
|
<tt>slot-value-using-class</tt>.
|
|
<P>
|
|
Implementations may optimize <tt>slot-value</tt> by compiling it in-line.
|
|
<P>
|
|
See <tt>slot-missing</tt> and <tt>slot-unbound</tt>.
|
|
<P>
|
|
[At this point the original CLOS report [<A HREF="node368.html#SIGPLANCLOS">5</A>,<A HREF="node368.html#LASCCLOSPART2">7</A>]
|
|
contained a specification for <tt>symbol-macrolet</tt>.
|
|
This specification is omitted here. Instead, a description
|
|
of <tt>symbol-macrolet</tt> appears with those of related constructs in chapter <A HREF="node76.html#CONTRL">7</A>.-GLS]
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<tt>update-instance-for-different-class <i>previous</i> <i>current</i> &rest <i>initargs</i> </tt><BR>
|
|
<BR><b>[Primary method]</b><BR>
|
|
<pre>
|
|
update-instance-for-different-class (<i>previous</i> standard-object)
|
|
(<i>current</i> standard-object) &rest <i>initargs</i>
|
|
</pre>
|
|
<P>The generic function <tt>update-instance-for-different-class</tt> is not
|
|
intended to be called by programmers. Programmers may write
|
|
methods for it. This function is called only by the function <tt>change-class</tt>.
|
|
<P>
|
|
The system-supplied primary method on
|
|
<tt>update-instance-for-different-class</tt> checks the validity of
|
|
initialization arguments and signals an error if an initialization
|
|
argument is supplied that is not declared valid. This method then
|
|
initializes slots with values according to the initialization
|
|
arguments and initializes the newly added slots with values according
|
|
to their <tt>:initform</tt> forms. It does this by calling the generic
|
|
function <tt>shared-initialize</tt> with the following arguments: the instance,
|
|
a list of names of the newly added slots, and the initialization
|
|
arguments it received. Newly added slots are those local slots for which
|
|
no slot of the same name exists in the previous class.
|
|
<P>
|
|
Methods for
|
|
<tt>update-instance-for-different-class</tt>
|
|
can be defined to
|
|
specify actions to be taken when an instance is updated. If only
|
|
<tt>:after</tt> methods for <tt>update-instance-for-different-class</tt> are
|
|
defined, they will be run after the system-supplied primary method for
|
|
initialization and therefore will not interfere with the default
|
|
behavior of <tt>update-instance-for-different-class</tt>.
|
|
<P>
|
|
The arguments to <tt>update-instance-for-different-class</tt> are
|
|
computed by <tt>change-class</tt>. When <tt>change-class</tt> is invoked on
|
|
an instance, a copy of that instance is made; <tt>change-class</tt> then
|
|
destructively alters the original instance. The first argument to
|
|
<tt>update-instance-for-different-class</tt>, <i>previous</i>, is that
|
|
copy; it holds the old slot values temporarily. This argument has
|
|
dynamic extent within <tt>change-class</tt>; if it is referenced in any
|
|
way once <tt>update-instance-for-different-class</tt> returns, the
|
|
results are undefined. The second argument to
|
|
<tt>update-instance-for-different-class</tt>, <i>current</i>, is the altered
|
|
original instance.
|
|
<P>
|
|
The intended use of <i>previous</i> is to extract old slot values by using
|
|
<tt>slot-value</tt> or <tt>with-slots</tt> or by invoking a reader generic
|
|
function, or to run other methods that were applicable to instances of
|
|
the original class.
|
|
<P>
|
|
The <i>initargs</i> argument consists of alternating initialization
|
|
argument names and values.
|
|
<P>
|
|
The value returned by <tt>update-instance-for-different-class</tt> is
|
|
ignored by <tt>change-class</tt>.
|
|
<P>
|
|
See the example for the function <tt>change-class</tt>.
|
|
<P>
|
|
Initialization arguments are declared valid by using the
|
|
<tt>:initarg</tt> option to <tt>defclass</tt>, or by defining methods for
|
|
<tt>update-instance-for-different-class</tt> or <tt>shared-initialize</tt>. The
|
|
keyword name of each keyword parameter specifier in the lambda-list of
|
|
any method defined on <tt>update-instance-for-different-class</tt> or
|
|
<tt>shared-initialize</tt> is declared a valid initialization argument name
|
|
for all classes for which that method is applicable.
|
|
<P>
|
|
Methods on <tt>update-instance-for-different-class</tt> can be defined to
|
|
initialize slots differently from <tt>change-class</tt>. The default
|
|
behavior of <tt>change-class</tt> is described in
|
|
section <A HREF="node305.html#ChangingtheClassofanInstanceSECTION">28.1.11</A>.
|
|
<P>
|
|
See sections <A HREF="node305.html#ChangingtheClassofanInstanceSECTION">28.1.11</A>,
|
|
<A HREF="node296.html#RulesforInitializationArgumentsSECTION">28.1.9.4</A>, and
|
|
<A HREF="node294.html#DeclaringtheValidityofInitializationArgumentsSECTION">28.1.9.2</A> as well as
|
|
<tt>change-class</tt> and <tt>shared-initialize</tt>.
|
|
<P>
|
|
|
|
<P>
|
|
<BR><b>[Generic function]</b><BR>
|
|
<pre>
|
|
update-instance-for-redefined-class <i>instance</i>
|
|
<i>added-slots</i> <i>discarded-slots</i> <i>property-list</i>
|
|
&rest <i>initargs</i>
|
|
</pre>
|
|
<b>[Primary method]</b><BR>
|
|
<pre>
|
|
update-instance-for-redefined-class (<i>instance</i> standard-object)
|
|
<i>added-slots</i> <i>discarded-slots</i> <i>property-list</i>
|
|
&rest <i>initargs</i>
|
|
</pre>
|
|
<P>The generic function <tt>update-instance-for-redefined-class</tt> is not
|
|
intended to be called by programmers. Programmers may
|
|
write methods for it. The generic function
|
|
<tt>update-instance-for-redefined-class</tt> is called by the mechanism
|
|
activated by <tt>make-instances-obsolete</tt>.
|
|
<P>
|
|
The system-supplied primary method on
|
|
<tt>update-instance-for-different-class</tt> checks the validity of
|
|
initialization arguments and signals an error if an initialization
|
|
argument is supplied that is not declared valid. This method then
|
|
initializes slots with values according to the initialization
|
|
arguments and initializes the newly added slots with values according
|
|
to their <tt>:initform</tt> forms. It does this by calling the generic
|
|
function <tt>shared-initialize</tt> with the following arguments: the instance,
|
|
a list of names of the newly added slots, and the initialization
|
|
arguments it received. Newly added slots are those local slots for which
|
|
no slot of the same name exists in the old version of the class.
|
|
<P>
|
|
When <tt>make-instances-obsolete</tt> is invoked or when a class has been
|
|
redefined and an instance is being updated, a property list is created
|
|
that captures the slot names and values of all the discarded slots with
|
|
values in the original instance. The structure of the instance is
|
|
transformed so that it conforms to the current class definition. The
|
|
arguments to <tt>update-instance-for-redefined-class</tt> are this
|
|
transformed instance, a list of the names of the new slots added to the
|
|
instance, a list of the names of the old slots discarded from the
|
|
instance, and the property list containing the slot names and values for
|
|
slots that were discarded and had values. Included in this list of
|
|
discarded slots are slots that were local in the old class and are
|
|
shared in the new class.
|
|
<P>
|
|
The <i>initargs</i> argument consists of alternating initialization
|
|
argument names and values.
|
|
<P>
|
|
The value returned by <tt>update-instance-for-redefined-class</tt> is ignored.
|
|
<P>
|
|
Initialization arguments are declared valid by using the
|
|
<tt>:initarg</tt> option to <tt>defclass</tt> or by defining methods for
|
|
<tt>update-instance-for-redefined-class</tt> or <tt>shared-initialize</tt>. The
|
|
keyword name of each keyword parameter specifier in the lambda-list of
|
|
any method defined on <tt>update-instance-for-redefined-class</tt> or
|
|
<tt>shared-initialize</tt> is declared a valid initialization argument name
|
|
for all classes for which that method is applicable.
|
|
<P>
|
|
See sections <A HREF="node300.html#RedefiningClassesSECTION">28.1.10</A>,
|
|
<A HREF="node296.html#RulesforInitializationArgumentsSECTION">28.1.9.4</A>, and
|
|
<A HREF="node294.html#DeclaringtheValidityofInitializationArgumentsSECTION">28.1.9.2</A> as well as
|
|
<tt>shared-initialize</tt> and <tt>make-instances-obsolete</tt>.
|
|
<P>
|
|
<P><pre>
|
|
(defclass position () ())
|
|
|
|
(defclass x-y-position (position)
|
|
((x :initform 0 :accessor position-x)
|
|
(y :initform 0 :accessor position-y)))
|
|
|
|
;;; It turns out polar coordinates are used more than Cartesian
|
|
;;; coordinates, so the representation is altered and some new
|
|
;;; accessor methods are added.
|
|
|
|
(defmethod update-instance-for-redefined-class :before
|
|
((pos x-y-position) added deleted plist &key)
|
|
;; Transform the x-y coordinates to polar coordinates
|
|
;; and store into the new slots.
|
|
(let ((x (getf plist 'x))
|
|
(y (getf plist 'y)))
|
|
(setf (position-rho pos) (sqrt (+ (* x x) (* y y)))
|
|
(position-theta pos) (atan y x))))
|
|
|
|
(defclass x-y-position (position)
|
|
((rho :initform 0 :accessor position-rho)
|
|
(theta :initform 0 :accessor position-theta)))
|
|
|
|
;;; All instances of the old x-y-position class will be updated
|
|
;;; automatically.
|
|
|
|
;;; The new representation has the look and feel of the old one.
|
|
|
|
(defmethod position-x ((pos x-y-position))
|
|
(with-slots (rho theta) pos (* rho (cos theta))))
|
|
|
|
(defmethod (setf position-x) (new-x (pos x-y-position))
|
|
(with-slots (rho theta) pos
|
|
(let ((y (position-y pos)))
|
|
(setq rho (sqrt (+ (* new-x new-x) (* y y)))
|
|
theta (atan y new-x))
|
|
new-x)))
|
|
|
|
(defmethod position-y ((pos x-y-position))
|
|
(with-slots (rho theta) pos (* rho (sin theta))))
|
|
</pre><P>
|
|
<P><pre>
|
|
(defmethod (setf position-y) (new-y (pos x-y-position))
|
|
(with-slots (rho theta) pos
|
|
(let ((x (position-x pos)))
|
|
(setq rho (sqrt (+ (* x x) (* new-y new-y)))
|
|
theta (atan new-y x))
|
|
new-y)))
|
|
</pre><P>
|
|
<P>
|
|
<BR><b>[Macro]</b><BR>
|
|
<pre>
|
|
with-accessors ({<i>slot-entry</i>}*) <i>instance-form</i>
|
|
{<i>declaration</i>}* {<i>form</i>}*
|
|
</pre>
|
|
<P>The macro <tt>with-accessors</tt> creates a lexical environment in which
|
|
specified slots are lexically available through their accessors as if
|
|
they were variables. The macro <tt>with-accessors</tt> invokes the
|
|
appropriate accessors to access the specified slots. Both <tt>setf</tt>
|
|
and <tt>setq</tt> can be used to set the value of the slot.
|
|
<P>
|
|
The result returned is that obtained by executing the forms specified
|
|
by the <i>body</i> argument.
|
|
<P>
|
|
Example:
|
|
<P>
|
|
<P><pre>
|
|
(with-accessors ((x position-x) (y position-y)) p1
|
|
(setq x y))
|
|
</pre><P>
|
|
<P>
|
|
A <tt>with-accessors</tt> expression of the form
|
|
<P><pre>
|
|
(with-accessors (<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43705.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43707.gif">) <i>instance</i>
|
|
<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43681.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43711.gif">)
|
|
<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43701.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43687.gif">)
|
|
</pre><P>
|
|
expands into the equivalent of
|
|
<P><pre>
|
|
(let ((<i>in</i> <i>instance</i>))
|
|
(symbol-macrolet ((<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43689.gif"> (<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43691.gif"> <i>in</i>))
|
|
...
|
|
(<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43693.gif"> (<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43695.gif"> <i>in</i>)))
|
|
<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43681.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43711.gif">)
|
|
<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43701.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43687.gif">)
|
|
</pre><P>
|
|
<P>
|
|
[X3J13 voted in March 1989
|
|
(SYMBOL-MACROLET-SEMANTICS) <A NAME=35675> </A>
|
|
to modify the definition of <tt>symbol-macrolet</tt> substantially
|
|
and also voted
|
|
(SYMBOL-MACROLET-DECLARE) <A NAME=35677> </A> to allow declarations before the body
|
|
of <tt>symbol-macrolet</tt> but with peculiar treatment of <tt>special</tt>
|
|
and type declarations. The syntactic changes are reflected in this definition
|
|
of <tt>with-accessors</tt>.-GLS]
|
|
<P>
|
|
See <tt>with-slots</tt> and <tt>symbol-macrolet</tt>.
|
|
<P>
|
|
<BR><b>[Special Form]</b><BR>
|
|
<pre>
|
|
with-added-methods (<i>function-name</i> <i>lambda-list</i>
|
|
<b>[[</b>?<i>option</i> | {<i>method-description</i>}*<b>]]</b>)
|
|
{<i>form</i>}*
|
|
</pre>
|
|
<P>The <tt>with-added-methods</tt> special form
|
|
produces new generic functions and establishes new
|
|
lexical function definition bindings. Each generic function is created by
|
|
adding the set of methods specified by its method definitions to a copy of the
|
|
lexically visible generic function of the same name and its methods. If
|
|
such a generic function does not already exist, a new generic function is
|
|
created; this generic function has lexical scope.
|
|
<P>
|
|
The special form <tt>with-added-methods</tt> is used to define functions
|
|
whose names are meaningful only locally and to execute a series of
|
|
forms with these function definition bindings.
|
|
<P>
|
|
The names of functions defined by <tt>with-added-methods</tt> have lexical
|
|
scope; they retain their local definitions only within the body of the
|
|
<tt>with-added-methods</tt> construct. Any references within the body of the
|
|
<tt>with-added-methods</tt> construct to functions whose names are the same
|
|
as those defined within the <tt>with-added-methods</tt> form are thus
|
|
references to the local functions instead of to any global functions
|
|
of the same names. The scope of these generic function definition bindings
|
|
includes the method bodies themselves as well as the body of the
|
|
<tt>with-added-methods</tt> construct.
|
|
<P>
|
|
The <i>function-name</i>, <i>option</i>, <i>method-qualifier</i>, and <i>specialized-lambda-list</i> arguments are the same as for <tt>defgeneric</tt>.
|
|
<P>
|
|
The body of each method is enclosed in an implicit block. If
|
|
<i>function-name</i> is a symbol, this block bears the same name as the
|
|
generic function. If <i>function-name</i> is a list of the form
|
|
<tt>(setf <i>symbol</i>)</tt>, the name of the block is <i>symbol</i>.
|
|
<P>
|
|
The result returned by <tt>with-added-methods</tt> is the value or values
|
|
of the last form executed. If no forms are specified,
|
|
<tt>with-added-methods</tt> returns <tt>nil</tt>.
|
|
<P>
|
|
If a generic function with the given name already exists, the
|
|
lambda-list specified in the <tt>with-added-methods</tt> form must be
|
|
congruent with the lambda-lists of all existing methods on that
|
|
function as well as with the lambda-lists of all methods defined by the
|
|
<tt>with-added-methods</tt> form; otherwise an error is signaled.
|
|
<P>
|
|
If <i>function-name</i> specifies an existing generic function that has a
|
|
different value for any of the following <i>option</i> arguments, the
|
|
copy of that generic function is modified to have the new value:
|
|
<tt>:argument-precedence-order</tt>, <tt>declare</tt>, <tt>:documentation</tt>,
|
|
<tt>:generic-function-class</tt>, <tt>:method-combination</tt>.
|
|
<P>
|
|
If <i>function-name</i> specifies an existing generic function that has a
|
|
different value for the <tt>:method-class</tt> <i>option</i> argument,
|
|
that value is changed in the copy of that generic function, but any
|
|
methods copied from the existing generic function are not changed.
|
|
<P>
|
|
If a function of the given name already exists, that function is copied into
|
|
the default method for a generic function of the given name. Note that
|
|
this behavior differs from that of <tt>defgeneric</tt>.
|
|
<P>
|
|
If a macro or special form of the given name already exists, an error
|
|
is signaled.
|
|
<P>
|
|
If there is no existing generic function, the <i>option</i> arguments have
|
|
the same default values as the <i>option</i> arguments to <tt>defgeneric</tt>.
|
|
<P>
|
|
See <tt>generic-labels</tt>,
|
|
<tt>generic-flet</tt>,
|
|
<tt>defmethod</tt>,
|
|
<tt>defgeneric</tt>,
|
|
and <tt>ensure-generic-function</tt>.
|
|
<P>
|
|
<BR><b>[Macro]</b><BR>
|
|
<pre>
|
|
with-slots ({<i>slot-entry</i>}*) <i>instance-form</i>
|
|
{<i>declaration</i>}* {<i>form</i>}*
|
|
|
|
<i>slot-entry</i> ::= <i>slot-name</i> | (<i>variable-name</i> <i>slot-name</i>)
|
|
</pre>
|
|
The macro <tt>with-slots</tt> creates a lexical context for referring to
|
|
specified slots as though they were variables. Within such a context
|
|
the value of the slot can be specified by using its slot name, as if
|
|
it were a lexically bound variable. Both <tt>setf</tt> and <tt>setq</tt>
|
|
can be used to set the value of the slot.
|
|
<P>
|
|
The macro <tt>with-slots</tt> translates an appearance of the slot name as
|
|
a variable into a call to <tt>slot-value</tt>.
|
|
<P>
|
|
The result returned is that obtained by executing the forms specified
|
|
by the <i>body</i> argument.
|
|
<P>
|
|
Example:
|
|
<P>
|
|
<P><pre>
|
|
(with-slots (x y) position-1
|
|
(sqrt (+ (* x x) (* y y))))
|
|
|
|
(with-slots ((x1 x) (y1 y)) position-1
|
|
(with-slots ((x2 x) (y2 y)) position-2
|
|
(psetf x1 x2
|
|
y1 y2))))
|
|
|
|
(with-slots (x y) position
|
|
(setq x (1+ x)
|
|
y (1+ y)))
|
|
</pre><P>
|
|
<P>
|
|
A <tt>with-slots</tt> expression of the form:
|
|
<P><pre>
|
|
(with-slots (<i><IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43705.gif"></i> ... <i><IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43707.gif"></i>) <i>instance</i>
|
|
<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43681.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43711.gif">)
|
|
<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43701.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43687.gif">)
|
|
</pre><P>
|
|
expands into the equivalent of
|
|
<P><pre>
|
|
(let ((<i>in</i> <i>instance</i>))
|
|
(symbol-macrolet (<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43717.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43719.gif">)
|
|
<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43681.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43711.gif">)
|
|
<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43701.gif"> ... <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43687.gif">)
|
|
</pre><P>
|
|
where <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43729.gif"> is
|
|
<P><pre>
|
|
(<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43731.gif"> (slot-value <i>in</i> '<i><IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43731.gif"></i>))
|
|
</pre><P>
|
|
if <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43735.gif"> is a symbol and is
|
|
<P><pre>
|
|
(<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43737.gif"> (slot-value <i>in</i> '<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43739.gif">))
|
|
</pre><P>
|
|
if <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43735.gif">
|
|
is of the form <tt>(<IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43737.gif"> <IMG ALIGN=BOTTOM ALT="" SRC="_24769_tex2html_wrap43739.gif">)</tt>.
|
|
<P>
|
|
[X3J13 voted in March 1989
|
|
(SYMBOL-MACROLET-SEMANTICS) <A NAME=35802> </A>
|
|
to modify the definition of <tt>symbol-macrolet</tt> substantially
|
|
and also voted
|
|
(SYMBOL-MACROLET-DECLARE) <A NAME=35804> </A> to allow declarations before the body
|
|
of <tt>symbol-macrolet</tt> but with peculiar treatment of <tt>special</tt>
|
|
and type declarations. The syntactic changes are reflected in this definition
|
|
of <tt>with-slots</tt>.-GLS]
|
|
<P>
|
|
See <tt>with-accessors</tt> and <tt>symbol-macrolet</tt>.
|
|
|
|
<br><img align=bottom alt="change_end" src="gif/change_end.gif">
|
|
|
|
<BR> <HR><A NAME=tex2html5535 HREF="node312.html"><IMG ALIGN=BOTTOM ALT="next" SRC="icons/next_motif.gif"></A> <A NAME=tex2html5533 HREF="node260.html"><IMG ALIGN=BOTTOM ALT="up" SRC="icons/up_motif.gif"></A> <A NAME=tex2html5529 HREF="node310.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="icons/previous_motif.gif"></A> <A NAME=tex2html5537 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="icons/contents_motif.gif"></A> <A NAME=tex2html5538 HREF="index.html"><IMG ALIGN=BOTTOM ALT="index" SRC="icons/index_motif.gif"></A> <BR>
|
|
<B> Next:</B> <A NAME=tex2html5536 HREF="node312.html"> Conditions</A>
|
|
<B>Up:</B> <A NAME=tex2html5534 HREF="node260.html"> Common Lisp Object </A>
|
|
<B> Previous:</B> <A NAME=tex2html5530 HREF="node310.html"> Customizing Reinitialization</A>
|
|
<HR> <P>
|
|
<HR>
|
|
<P><ADDRESS>
|
|
AI.Repository@cs.cmu.edu
|
|
</ADDRESS>
|
|
</BODY>
|