X-Git-Url: https://git.distorted.org.uk/~mdw/sod/blobdiff_plain/756e9293611d2b1dc34fba6cca89fd70098f5546..d82d5db50317a9ebed40492a9cd59f941c9d8e58:/doc/concepts.tex

diff --git a/doc/concepts.tex b/doc/concepts.tex
index e301ae7..1af615d 100644
--- a/doc/concepts.tex
+++ b/doc/concepts.tex
@@ -122,11 +122,11 @@ superclasses.
 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
@@ -148,7 +148,7 @@ following properties are expected to hold.
   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
@@ -288,8 +288,10 @@ and its type is usually @|SodClass|; @|SodClass|'s nickname is @|cls|.
 
 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
@@ -314,7 +316,7 @@ There are three main cases to distinguish.
   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
@@ -463,9 +465,8 @@ constructed: the vtables contain null pointers in place of pointers to method
 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,
@@ -544,7 +545,7 @@ entry functions.
       {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}
@@ -847,8 +848,8 @@ other method takes steps to prevent this.
 
 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}
