Every object is a \emph{direct instance} of exactly one \emph{class}. The
class determines which slots its instances have, which messages its instances
-can be sent, and which methods are invoked when those messages are received.
-The Sod translator's main job is to read class definitions and convert them
-into appropriate C declarations, tables, and functions. An object cannot
-(usually) change its direct class, and the direct class of an object is not
-affected by, for example, the static type of a pointer to it.
+can be sent, and which \emph{methods} are invoked when those messages are
+received. The Sod translator's main job is to read class definitions and
+convert them into appropriate C declarations, tables, and functions. An
+object cannot (usually) change its direct class, and the direct class of an
+object is not affected by, for example, the static type of a pointer to it.
If an object~$x$ is a direct instance of some class~$C$, then we say that $C$
is \emph{the class of}~$x$. Note that the class of an object is a property
$C$, we shall need to extend it into a total order on $C$'s superclasses.
This calculation is called \emph{superclass linearization}, and the result is
a \emph{class precedence list}, which lists each of $C$'s superclasses
-exactly once. If a superclass $B$ precedes (resp.\ follows) some other
-superclass $A$ in $C$'s class precedence list, then we say that $B$ is a more
-(resp.\ less) \emph{specific} superclass of $C$ than $A$ is.
+exactly once. If a superclass $B$ precedes or follows some other superclass
+$A$ in $C$'s class precedence list, then we say that $B$ is respectively a
+more or less \emph{specific} superclass of $C$ than $A$.
The superclass linearization algorithm isn't fixed, and extensions to the
translator can introduce new linearizations for special effects, but the
list, i.e., $B$ is a more specific superclass of $C$ than $A$ is.
\end{itemize}
The default linearization algorithm used in Sod is the \emph{C3} algorithm,
-which has a number of good properties described in~\cite{Barrett:1996:MSL}.
-It works as follows.
+which has a number of good properties described
+in~\cite{barrett-1996:monot-super-linear-dylan}. It works as follows.
\begin{itemize}
\item A \emph{merge} of some number of input lists is a single list
containing each item that is in any of the input lists exactly once, and no
\end{itemize}
- (This example combines elements from \cite{Barrett:1996:MSL} and
- \cite{Ducournau:1994:PMM}.)
+ (This example combines elements from
+ \cite{barrett-1996:monot-super-linear-dylan} and
+ \cite{ducournau-1994:monot-multip-inher-linear}.)
\end{example}
\subsubsection{Class links and chains}
\end{enumerate}
Perhaps surprisingly, keyword arguments have a relatively small performance
-impact. On the author's aging laptop, a call to a simple function, passing
+impact. On the author's ageing laptop, a call to a simple function, passing
two out of three keyword arguments, takes about 30 cycles longer than calling
a standard function which just takes integer arguments. On the other hand,
quite a lot of code is involved in decoding keyword arguments, so code size
acceptable, and, for each rôle, the appropriate argument lists and return
types.
-One direct method, $M$, is said to be more (resp.\ less) \emph{specific} than
+One direct method, $M$, is said to be more or less \emph{specific} than
another, $N$, with respect to a receiving class~$C$, if the class defining
-$M$ is a more (resp.\ less) specific superclass of~$C$ than the class
+$M$ is respectively a more or less specific superclass of~$C$ than the class
defining $N$.
\subsubsection{The standard method combination}
initializers, \emph{and} the sender supplied a value for one or more of the
corresponding effective initargs, then the value of the most specific such
initarg is stored in the slot. (For this purpose, initargs defined earlier
- in a class definition are more specific than initargs defined later.)
+ in a class definition are more specific than initargs defined
+ later.)\footnote{%
+ This is very different from the CLOS behaviour, in which a slot is
+ initialized from the first applicable initarg in the argument list.}
\item Otherwise, if there are any slot initializers defined which include an
initializer expression, then the initializer expression from the most
Metaobject classes are chosen in a fairly standard way.
\begin{itemize}
\item All metaobject definitions support a symbol-valued property, usually
- named @|@<thing>_class| (e.g., @|slot_class|, @|method_class|), which sets
+ named @|@<thing>{}_class| (e.g., @|slot_class|, @|method_class|), which sets
the metaobject class explicitly. (The class for a class metaobject is
taken from the @|lisp_class| property, because @|class_class| seems less
meaningful.)
~mdw / sod / blobdiff