-\section{Classes}
-\label{sec:class}
-
-\subsection{Classes and superclasses} \label{sec:class.defs}
-
-A @<full-class-definition> must list one or more existing classes to be the
-\emph{direct superclasses} for the new class being defined. We make the
-following definitions.
-\begin{itemize}
-\item The \emph{superclasses} of a class consist of the class itself together
- with the superclasses of its direct superclasses.
-\item The \emph{proper superclasses} of a class are its superclasses other
- than itself.
-\item If $C$ is a (proper) superclass of $D$ then $D$ is a (\emph{proper})
- \emph{subclass} of $C$.
-\end{itemize}
-The predefined class @|SodObject| has no direct superclasses; it is unique in
-this respect. All classes are subclasses of @|SodObject|.
-
-\subsection{The class precedence list} \label{sec:class.cpl}
-
-Let $C$ be a class. The superclasses of $C$ form a directed graph, with an
-edge from each class to each of its direct superclasses. This is the
-\emph{superclass graph of $C$}.
-
-In order to resolve inheritance of items, we define a \emph{class precedence
- list} (or CPL) for each class, which imposes a total order on that class's
-superclasses. The default algorithm for computing the CPL is the \emph{C3}
-algorithm \cite{fixme-c3}, though extensions may implement other algorithms.
-
-The default algorithm works as follows. Let $C$ be the class whose CPL we
-are to compute. Let $X$ and $Y$ be two of $C$'s superclasses.
-\begin{itemize}
-\item $C$ must appear first in the CPL.
-\item If $X$ appears before $Y$ in the CPL of one of $C$'s direct
- superclasses, then $X$ appears before $Y$ in the $C$'s CPL.
-\item If the above rules don't suffice to order $X$ and $Y$, then whichever
- of $X$ and $Y$ has a subclass which appears further left in the list of
- $C$'s direct superclasses will appear earlier in the CPL.
-\end{itemize}
-This last rule is sufficient to disambiguate because if both $X$ and $Y$ are
-superclasses of the same direct superclass of $C$ then that direct
-superclass's CPL will order $X$ and $Y$.
-
-We say that \emph{$X$ is more specific than $Y$ as a superclass of $C$} if
-$X$ is earlier than $Y$ in $C$'s class precedence list. If $C$ is clear from
-context then we omit it, saying simply that $X$ is more specific than $Y$.
-
-\subsection{Instances and metaclasses} \label{sec:class.meta}
-
-A class defines the structure and behaviour of its \emph{instances}: run-time
-objects created (possibly) dynamically. An instance is an instance of only
-one class, though structurally it may be used in place of an instance of any
-of that class's superclasses. It is possible, with care, to change the class
-of an instance at run-time.
-
-Classes are themselves represented as instances -- called \emph{class
- objects} -- in the running program. Being instances, they have a class,
-called the \emph{metaclass}. The metaclass defines the structure and
-behaviour of the class object.
-
-The predefined class @|SodClass| is the default metaclass for new classes.
-@|SodClass| has @|SodObject| as its only direct superclass. @|SodClass| is
-its own metaclass.
-
-To make matters more complicated, Sod has \emph{two} distinct metalevels: as
-well as the runtime metalevel, as discussed above, there's a compile-time
-metalevel hosted in the Sod translator. Since Sod is written in Common Lisp,
-a Sod class's compile-time metaclass is a CLOS class. The usual compile-time
-metaclass is @|sod-class|. The compile-time metalevel is the subject of
-\xref{ch:api}.
-
-\subsection{Items and inheritance} \label{sec:class.inherit}
-
-A class definition also declares \emph{slots}, \emph{messages},
-\emph{initializers} and \emph{methods} -- collectively referred to as
-\emph{items}. In addition to the items declared in the class definition --
-the class's \emph{direct items} -- a class also \emph{inherits} items from
-its superclasses.
-
-The precise rules for item inheritance vary according to the kinds of items
-involved.
-
-Some object systems have a notion of `repeated inheritance': if there are
-multiple paths in the superclass graph from a class to one of its
-superclasses then items defined in that superclass may appear duplicated in
-the subclass. Sod does not have this notion.
-
-\subsubsection{Slots} \label{sec:class.inherit.slots}
-A \emph{slot} is a unit of state. In other object systems, slots may be
-called `fields', `member variables', or `instance variables'.
-
-A slot has a \emph{name} and a \emph{type}. The name serves only to
-distinguish the slot from other direct slots defined by the same class. A
-class inherits all of its proper superclasses' slots. Slots inherited from
-superclasses do not conflict with each other or with direct slots, even if
-they have the same names.
-
-At run-time, each instance of the class holds a separate value for each slot,
-whether direct or inherited. Changing the value of an instance's slot
-doesn't affect other instances.
-
-\subsubsection{Initializers} \label{sec:class.inherit.init}
-Mumble.
-
-\subsubsection{Messages} \label{sec:class.inherit.messages}
-A \emph{message} is the stimulus for behaviour. In Sod, a class must define,
-statically, the name and format of the messages it is able to receive and the
-values it will return in reply. In this respect, a message is similar to
-`abstract member functions' or `interface member functions' in other object
-systems.
-
-Like slots, a message has a \emph{name} and a \emph{type}. Again, the name
-serves only to distinguish the message from other direct messages defined by
-the same class. Messages inherited from superclasses do not conflict with
-each other or with direct messages, even if they have the same name.
-
-At run-time, one sends a message to an instance by invoking a function
-obtained from the instance's \emph{vtable}: \xref{sec:fixme-vtable}.
-
-\subsubsection{Methods} \label{sec:class.inherit.methods}
-A \emph{method} is a unit of behaviour. In other object systems, methods may
-be called `member functions'.
-
-A method is associated with a message. When a message is received by an
-instance, all of the methods associated with that message on the instance's
-class or any of its superclasses are \emph{applicable}. The details of how
-the applicable methods are invoked are described fully in
-\xref{sec:fixme-method-combination}.
-
-\subsection{Chains and instance layout} \label{sec:class.layout}
-
-C is a rather low-level language, and in particular it exposes details of the
-way data is laid out in memory. Since an instance of a class~$C$ should be
-(at least in principle) usable anywhere an instance of some superclass $B
-\succeq C$ is expected, this implies that an instance of the subclass $C$
-needs to contain within it a complete instance of each superclass $B$, laid
-out according to the rules of instances of $B$, so that if we have (the
-address of) an instance of $C$, we can easily construct a pointer to a thing
-which looks like an instance of $B$ contained within it.
-
-Specifically, the information we need to retain for an instance of a
-class~$C$ is:
-\begin{itemize}
-\item the values of each of the slots defined by $C$, including those defined
- by superclasses;
-\item information which will let us convert a pointer to $C$ into a pointer
- to any superclass $B \succeq C$;
-\item information which will let us call the appropriate effective method for
- each message defined by $C$, including those defined by superclasses; and
-\item some additional meta-level information, such as how to find the class
- object for $C$ given (the address of) one of its instances.
-\end{itemize}
-
-Observe that, while each distinct instance must clearly have its own storage
-for slots, all instances of $C$ can share a single copy of the remaining
-information. The individual instance only needs to keep a pointer to this
-shared table, which, inspired by the similar structure in many \Cplusplus\
-ABIs, are called a \emph{vtable}.
-
-The easiest approach would be to decide that instances of $C$ are exactly
-like instances of $B$, only with extra space at the end for the extra slots
-which $C$ defines over and above those already existing in $B$. Conversion
-is then trivial: a pointer to an instance of $C$ can be converted to a
-pointer to an instance of some superclass $B$ simply by casting. Even though
-the root class @|SodObject| doesn't have any slots at all, its instances will
-still need a vtable so that you can find its class object: the address of the
-vtable therefore needs to be at the very start of the instance structure.
-Again, a vtable for a superclass would have a vtable for each of its
-superclasses as a prefix, with new items added afterwards.
-
-This appealing approach works well for an object system which only permits
-single inheritance of both state and behaviour. Alas, it breaks down when
-multiple inheritance is allowed: $C$ can be a subclass of both $B$ and $B'$,
-even though $B$ is not a subclass of $B'$, nor \emph{vice versa}; so, in
-general, $B$'s instance structure will not be a prefix of $B'$'s, nor will
-$B'$'s be a prefix of $B$'s, and therefore $C$ cannot have both $B$ and $B'$
-as a prefix.
-
-A (non-root) class may -- though need not -- have a distinguished \emph{link}
-superclass, which need not be a direct superclass. Furthermore, each
-class~$C$ must satisfy the \emph{chain condition}: for any superclass $A$ of
-$C$, there can be at most one other superclass of $C$ whose link superclass
-is $A$.\footnote{%
- That is, it's permitted for two classes $B$ and $B'$ to have the same link
- superclass $A$, but $B$ and $B'$ can't then both be superclasses of the
- same class $C$.} %
-Therefore, the links partition the superclasses of~$C$ into nice linear
-\emph{chains}, such that each superclass is a member of exactly one chain.
-If a class~$B$ has a link superclass~$A$, then $B$'s \emph{level} is one more
-than that of $A$; otherwise $B$ is called a \emph{chain head} and its level
-is zero. If the classes in a chain are written in a list, chain head first,
-then the level of each class gives its index in the list.
-
-Chains therefore allow us to recover some of the linearity properties which
-made layout simple in the case of single inheritance. The instance structure
-for a class $C$ contains a substructure for each of $C$'s superclass chains;
-a pointer to an object of class $C$ actually points to the substructure for
-the chain containing $C$. The order of these substructures is unimportant
-for now.\footnote{%
- The chains appear in the order in which their most specific classes appear
- in $C$'s class precedence list. This guarantees that the chain containing
- $C$ itself appears first, so that a pointer to $C$'s instance structure is
- actually a pointer to $C$'s chain substructure. Apart from that, it's a
- simple, stable, but basically arbitrary choice which can't be changed
- without breaking the ABI.} %
-The substructure for each chain begins with a pointer to a vtable, followed
-by a structure for each superclass in the chain containing the slots defined
-by that superclass, with the chain head (least specific class) first.
-
-Suppose we have a pointer to (static) type $C$, and want to convert it into a
-pointer to some superclass $B$ of $C$ -- an \emph{upcast}.\footnote{%
- In the more general case, we have a pointer to static type $C$, which
- actually points to an object of some subclass $D$ of $C$, and want to
- convert it into a pointer to type $B$. Such a conversion is called a
- \emph{downcast} if $B$ is a subclass of $C$, or a \emph{cross-cast}
- otherwise. Downcasts and cross-casts require complicated run-time
- checking, and can will fail unless $B$ is a superclass of $D$.} %
-If $B$ is in the same chain as $C$ -- an \emph{in-chain upcast} -- then the
-pointer value is already correct and it's only necessary to cast it
-appropriately. Otherwise -- a \emph{cross-chain upcast} -- the pointer needs
-to be adjusted to point to a different chain substructure. Since the lengths
-and relative positions of the chain substructures vary between classes, the
-adjustments are stored in the vtable. Cross-chain upcasts are therefore a
-bit slower than in-chain upcasts.
-
-Each chain has its own separate vtable, because much of the metadata stored
-in the vtable is specific to a particular chain. For example:
-\begin{itemize}
-\item offsets to other chains' substructures will vary depending on which
- chain we start from; and
-\item entry points to methods {