From: Mark Wooding Date: Sat, 9 Jun 2018 02:49:16 +0000 (+0100) Subject: doc/: Fix various unfortunate garblings. X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~mdw/git/sod/commitdiff_plain/756e9293611d2b1dc34fba6cca89fd70098f5546 doc/: Fix various unfortunate garblings. --- diff --git a/doc/concepts.tex b/doc/concepts.tex index 406c002..e301ae7 100644 --- a/doc/concepts.tex +++ b/doc/concepts.tex @@ -177,11 +177,12 @@ a link superclass, and the link superclass of a class $C$, if it exists, need 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 @@ -606,7 +607,7 @@ follows (see also~\xref{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 @@ -812,8 +813,8 @@ imprint storage for one of that class's instances. 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 @

as an instance of a class, given a pointer to its class object @. @@ -875,9 +876,9 @@ There are two kinds of initarg definitions. \emph{User initargs} are defined 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| diff --git a/doc/intro.tex b/doc/intro.tex index f4b3168..f77eed0 100644 --- a/doc/intro.tex +++ b/doc/intro.tex @@ -88,7 +88,7 @@ are subclasses; \Cplusplus\ has no such root class. Both systems provide multiple inheritance, but go about it very differently. The most important difference is that \Cplusplus\ provides only \emph{static delegation}: if you have a class @|B| which defines some (virtual) member -function @|f|, and a derived class of @|D| which wants to \emph{extend} the +function @|f|, and a derived class @|D| which wants to \emph{extend} the behaviour of @|f| on instances of @|D|, then you must explicitly call @|B::f| at the appropriate point: \begin{prog} diff --git a/doc/structures.tex b/doc/structures.tex index 2dfe355..b2835fe 100644 --- a/doc/structures.tex +++ b/doc/structures.tex @@ -444,7 +444,7 @@ vtable pointer In general, the vtables for the different chains will have \emph{different} structures. -The instance layout split neatly into disjoint chains. This is necessary +The instance layout splits neatly into disjoint chains. This is necessary because each @|ichain| must have as a prefix the @|ichain| for each superclass in the same chain, and each slot must be stored in exactly one place. The layout of vtables doesn't have this second requirement: it diff --git a/lib/sod-structs.3 b/lib/sod-structs.3 index 672fe59..a515c8e 100644 --- a/lib/sod-structs.3 +++ b/lib/sod-structs.3 @@ -692,7 +692,7 @@ will have .I different structures. .PP -The instance layout split neatly into disjoint chains. +The instance layout splits neatly into disjoint chains. This is necessary because each .B ichain