Work in progress, recovered from old crybaby.

[sod] / src / classes.lisp

diff --git a/src/classes.lisp b/src/classes.lisp
index 3d01f57..c81c41e 100644 (file)
--- 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