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
not be a direct superclass of $C$.
Superclass links must obey the following rule: if $C$ is a class, then there
-must be no three superclasses $X$, $Y$ and~$Z$ of $C$ such that $Z$ is the
-link superclass of both $X$ and $Y$. As a consequence of this rule, the
-superclasses of $C$ can be partitioned into linear \emph{chains}, such that
-superclasses $A$ and $B$ are in the same chain if and only if one can trace a
-path from $A$ to $B$ by following superclass links, or \emph{vice versa}.
+must be no three distinct superclasses $X$, $Y$ and~$Z$ of $C$ such that $Z$
+is the link superclass of both $X$ and $Y$. As a consequence of this rule,
+the superclasses of $C$ can be partitioned into linear \emph{chains}, such
+that superclasses $A$ and $B$ are in the same chain if and only if one can
+trace a path from $A$ to $B$ by following superclass links, or \emph{vice
+versa}.
Since a class links only to one of its proper superclasses, the classes in a
chain are naturally ordered from most- to least-specific. The least specific
the private structure can grow more members as needed. See
\xref{sec:fixme.compatibility} for more details.)
+
\subsubsection{Vtables}
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}
A typical use for @|around| methods is to allow a base class to set up the
dynamic environment appropriately for the primary methods of its subclasses,
-e.g., by claiming a lock, and restore it afterwards.
+e.g., by claiming a lock, and releasing it afterwards.
The @|next_method| function provided to methods with the primary and
@|around| rôles accepts the same arguments, and returns the same type, as the
Once an instance's storage has been imprinted, it is technically possible to
send messages to the instance; however the instance's slots are still
-uninitialized at this point, the applicable methods are unlikely to do much
-of any use unless they've been written specifically for the purpose.
+uninitialized at this point, so the applicable methods are unlikely to do
+much of any use unless they've been written specifically for the purpose.
The following simple function imprints storage at address @<p> as an instance
of a class, given a pointer to its class object @<cls>.
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}
by an explicit @|initarg| item appearing in a class definition: the item
defines a name, type, and (optionally) a default value for the initarg.
\emph{Slot initargs} are defined by attaching an @|initarg| property to a
-slot or slot initializer item: the property's determines the initarg's name,
-while the type is taken from the underlying slot type; slot initargs do not
-have default values. Both kinds define a \emph{direct initarg} for the
+slot or slot initializer item: the property's value determines the initarg's
+name, while the type is taken from the underlying slot type; slot initargs do
+not have default values. Both kinds define a \emph{direct initarg} for the
containing class.
Initargs are inherited. The \emph{applicable} direct initargs for an @|init|
~mdw / sod / blobdiff