chiark / gitweb /
doc/: Fix various unfortunate garblings.
authorMark Wooding <mdw@distorted.org.uk>
Sat, 9 Jun 2018 02:49:16 +0000 (03:49 +0100)
committerMark Wooding <mdw@distorted.org.uk>
Sat, 9 Jun 2018 02:52:28 +0000 (03:52 +0100)
doc/concepts.tex
doc/intro.tex
doc/structures.tex
lib/sod-structs.3

index 406c002..e301ae7 100644 (file)
@@ -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 @<p> as an instance
 of a class, given a pointer to its class object @<cls>.
@@ -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|
index f4b3168..f77eed0 100644 (file)
@@ -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}
index 2dfe355..b2835fe 100644 (file)
@@ -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
index 672fe59..a515c8e 100644 (file)
@@ -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