$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}
a lookup at runtime to find the appropriate offset by which to adjust the
pointer. The conversion can be performed using the appropriate generated
upcast macro (see below); the general case is handled by the macro
- \descref{SOD_XCHAIN}{mac}.
+ \descref{mac}{SOD_XCHAIN}.
\item If $B$ is a subclass of~$C$ then the conversion is a \emph{downcast};
otherwise the conversion is a~\emph{cross-cast}. In either case, the
conversion can fail: the object in question might not be an instance of~$B$
- after all. The macro \descref{SOD_CONVERT}{mac} and the function
- \descref{sod_convert}{fun} perform general conversions. They return a null
+ after all. The macro \descref{mac}{SOD_CONVERT} and the function
+ \descref{fun}{sod_convert} perform general conversions. They return a null
pointer if the conversion fails. (These are therefore your analogue to the
\Cplusplus\ @|dynamic_cast<>| operator.)
\end{itemize}
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}
node [above right = 0mm and -8mm]
{$\vcenter{\hbox{\Huge\textcolor{red}{!}}}
\vcenter{\hbox{\begin{tabular}[c]{l}
- \textsf{next_method} \\
+ @|next_method| \\
pointer is null
\end{tabular}}}$};
instance's slots, and maybe links it into any external data structures as
necessary.
\end{enumerate}
-The \descref{SOD_DECL}[macro]{mac} handles constructing instances with
+The \descref{mac}{SOD_DECL}[macro] handles constructing instances with
automatic storage duration (`on the stack'). Similarly, the
-\descref{SOD_MAKE}[macro]{mac} and the \descref{sod_make}{fun} and
-\descref{sod_makev}{fun} functions construct instances allocated from the
+\descref{mac}{SOD_MAKE}[macro] and the \descref*{fun}{sod_make} and
+\descref{fun}{sod_makev} functions construct instances allocated from the
standard @|malloc| heap. Programmers can add support for other allocation
-strategies by using the \descref{SOD_INIT}[macro]{mac} and the
-\descref{sod_init}{fun} and \descref{sod_initv}{fun} functions, which package
-up imprinting and initialization.
+strategies by using the \descref{mac}{SOD_INIT}[macro] and the
+\descref*{fun}{sod_init} and \descref{fun}{sod_initv} functions, which
+package up imprinting and initialization.
\subsubsection{Allocation}
Instances of most classes (specifically including those classes defined by
Teardown alone, for objects which require special deallocation, or for which
deallocation occurs automatically (e.g., instances with automatic storage
duration, or instances whose storage will be garbage-collected), is performed
-using the \descref{sod_teardown}[function]{fun}. Destruction of instances
+using the \descref{fun}{sod_teardown}[function]. Destruction of instances
allocated from the standard @|malloc| heap is done using the
-\descref{sod_destroy}[function]{fun}.
+\descref{fun}{sod_destroy}[function].
\subsubsection{Teardown}
Details of teardown are necessarily class-specific, but typically it
[role = around] \\
int obj.teardown() \\
\{ \\ \ind
- if (--\,--me@->ref.nref) return (1); \\
+ if (@--me@->ref.nref) return (1); \\
else return (CALL_NEXT_METHOD); \-\\
\} \-\\
\}
The code which makes the decision to destroy an object may often not be aware
of the object's direct class. Low-level details of deallocation often
require the proper base address of the instance's storage, which can be
-determined using the \descref{SOD_INSTBASE}[macro]{mac}.
+determined using the \descref{mac}{SOD_INSTBASE}[macro].
%%%--------------------------------------------------------------------------
\section{Metaclasses} \label{sec:concepts.metaclasses}