If an object is a direct instance of class~$C$ then the object is also an
(indirect) instance of every superclass of $C$.
-If $C$ has a proper superclass $B$, then $B$ is not allowed to have $C$ has a
-direct superclass. In different terms, if we construct a graph, whose
-vertices are classes, and draw an edge from each class to each of its direct
-superclasses, then this graph must be acyclic. In yet other terms, the `is a
-superclass of' relation is a partial order on classes.
+If $C$ has a proper superclass $B$, then $B$ must not have $C$ as a direct
+superclass. In different terms, if we construct a graph, whose vertices are
+classes, and draw an edge from each class to each of its direct superclasses,
+then this graph must be acyclic. In yet other terms, the `is a superclass
+of' relation is a partial order on classes.
\subsubsection{The class precedence list}
This partial order is not quite sufficient for our purposes. For each class
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{FIXME:C3}.
+which has a number of good properties described in~\cite{Barrett:1996:MSL}.
It works as follows.
\begin{itemize}
\item A \emph{merge} of some number of input lists is a single list
A class object's slots contain or point to useful information, tables and
functions for working with that class's instances. (The @|SodClass| class
-doesn't define any messages, so it doesn't have any methods. In Sod, a class
-slot containing a function pointer is not at all the same thing as a method.)
+doesn't define any messages, so it doesn't have any methods other than for
+the @|SodObject| lifecycle messages @|init| and @|teardown|; see
+\xref{sec:concepts.lifecycle}. In Sod, a class slot containing a function
+pointer is not at all the same thing as a method.)
\subsubsection{Conversions}
Suppose one has a value of type pointer-to-class-type for some class~$C$, and
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
- pointer if the conversion fails. (There are therefore your analogue to the
+ pointer if the conversion fails. (These are therefore your analogue to the
\Cplusplus\ @|dynamic_cast<>| operator.)
\end{itemize}
The Sod translator generates macros for performing both in-chain and
entry functions.
\begin{figure}
- \begin{tikzpicture}
- [>=stealth, thick,
- order/.append style={color=green!70!black},
+ \hbox to\hsize{\hss\hbox{\begin{tikzpicture}
+ [order/.append style={color=green!70!black},
code/.append style={font=\sffamily},
action/.append style={font=\itshape},
method/.append style={rectangle, draw=black, thin, fill=blue!30,
{Least to \\ most \\ specific};
\draw [<-] ($(fn.north west) + (6mm, 1mm)$) -- ++(-8mm, 8mm);
- \end{tikzpicture}
+ \end{tikzpicture}}\hss}
\caption{The standard method combination}
\label{fig:concepts.methods.stdmeth}
Slots are initialized in a well-defined order.
\begin{itemize}
-\item Slots defined by a more specific superclasses are initialized after
- slots defined by a less specific superclass.
+\item Slots defined by a more specific superclass are initialized after slots
+ defined by a less specific superclass.
\item Slots defined by the same class are initialized in the order in which
their definitions appear.
\end{itemize}
~mdw / sod / blobdiff