(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'
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