X-Git-Url: https://git.distorted.org.uk/~mdw/sod/blobdiff_plain/dea4d05507e59ab779ed4bb209e05971d87e260c..bf090e021a5c20da452a4841cdfb8eb78e29544e:/src/classes.lisp

diff --git a/src/classes.lisp b/src/classes.lisp
index 3d01f57..c81c41e 100644
--- a/src/classes.lisp
+++ b/src/classes.lisp
@@ -326,7 +326,7 @@
    (class :initarg :class :type sod-class :reader sod-message-class)
    (type :initarg :type :type c-function-type :reader sod-message-type))
   (:documentation
-   "Messages the means for stimulating an object to behave.
+   "Messages are the means for stimulating an object to behave.
 
    SOD is a single-dispatch object system, like Smalltalk, C++, Python and so
    on, but unlike CLOS and Dylan.  Behaviour is invoked by `sending messages'
@@ -409,27 +409,27 @@
        will, in general, differ from the type of the message for several
        reasons.
 
-	 -- Firstly, the method type must include names for all of the
-            method's parameters.  The message definition can omit the
-            parameter names (in the same way as a function declaration can).
-            Formally, the message definition can contain abstract
-            declarators, whereas method definitions must not.
+	 -- The method type must include names for all of the method's
+	    parameters.  The message definition can omit the parameter
+	    names (in the same way as a function declaration can).  Formally,
+	    the message definition can contain abstract declarators, whereas
+	    method definitions must not.
 
 	 -- Method combinations may require different parameter or return
-            types.  For example, `before' and `after' methods don't
-            contribute to the message's return value, so they must be defined
-            as returning `void'.
+	    types.  For example, `before' and `after' methods don't
+	    contribute to the message's return value, so they must be defined
+	    as returning `void'.
 
 	 -- Method combinations may permit methods whose parameter and/or
-            return types don't exactly match the corresponding types of the
-            message.  For example, one might have methods with covariant
-            return types and contravariant parameter types.  (This sounds
-            nice, but it doesn't actually seem like such a clever idea when
-            you consider that the co-/contravariance must hold among all the
-            applicable methods ordered according to the class precedence
-            list.  As a result, a user might have to work hard to build
-            subclasses whose CPLs match the restrictions implied by the
-            method types.)
+	    return types don't exactly match the corresponding types of the
+	    message.  For example, one might have methods with covariant
+	    return types and contravariant parameter types.  (This sounds
+	    nice, but it doesn't actually seem like such a clever idea when
+	    you consider that the co-/contravariance must hold among all the
+	    applicable methods ordered according to the class precedence
+	    list.  As a result, a user might have to work hard to build
+	    subclasses whose CPLs match the restrictions implied by the
+	    method types.)
 
    Method objects are fairly passive in the SOD translator.  However,
    subclasses of `sod-message' may (and probably will) construct instances of