Comments on new draft chapter 2 (dated May 16 15:09)

["David A. Moon" <MOON@AI.AI.MIT.EDU>]

There is also one comment on chapter 1 in here.

2-6 first paragraph: I'm not sure what is meant by behavior intrinsic to a
generic function itself.  I think this probably means a contract that all
methods must obey (as distinguished from idiosyncratic behavior of one
particular method).

2-12: This says call-next-method signals an error, but I thought we
changed it to call a generic function whose default method signals an error.

2-15: In the defmethod, change "&rest initargs" to "&key" for better style,
since this method doesn't use or define any initargs, it should have an
empty set of &key parameters.  Also this method should be a :before method;
not a :after method, because we want to initialize the slots ourselves,
not let the primary method initialize them from initforms then reinitialize
them ourselves.  I think 1-44 and 1-47 should be modified to reflect this
valid use of :before methods for the two update- functions; they differ
in this respect from initialize-instance and reinitialize-instance.

2-17: The method signatures imply that only standard classes have names,
but I believe the intent was that all classes have names.  Certainly
built-in and structure classes do have names.

2-21 3rd paragraph: Someone complained that "The slot-name argument is
a symbol that can be used as a Common Lisp variable name." was ambiguous.
What we mean is that the symbol is syntactically valid for use as a
variable name, what we don't mean is that referencing a variable with
this name will access the slot.  This should be rephrased if possible.

2-33 last paragraph: The value returned by define-method-combination
should be the method combination meta object (now that we have them),
not the name.

2-37 2nd paragraph: I don't understand what this paragraph is doing
here.  Keyword options to what?  Did this paragraph drift in from
somewhere earlier in the define-method-combination section perhaps?

2-43: There is documentation for slot descriptor objects now too.
Since only chapter 3 describes those, I don't know whether slot
documentation should be documented in the normal way, or just
mentioned as a remark.  I think I prefer the former.

2-45 4th paragraph: Because of the way rule 4 for lambda-list
congruence is defined, I think this has to speak not of the old
and new lambda-lists for the generic function being congruent,
but of the new lambda-list for the generic function being congruent
with the lambda-lists of all existing methods.  If an implementation
can sometimes optimize this into a comparison with the old lambda
list for the generic function, that's merely an optimization.

2-55 2nd paragraph: I don't think the system supplied primary
method for initialize-instance checks the validity of the arguments,
since chapter 1 says make-instance takes care of that.  Unlike
reinitialize-instance, initialize-instance is not meant to be
called by the user.

2-55 Remarks field: This is not really accurate, as the generic
functions for which methods can be defined varies.  Chapter 1
describes this better, maybe the description should not be
repeated here.  It would be useful to have a remark that the programmer
is intended to define :after methods for initialize-instance.

2-58: Formatting of method signatures is particularly ugly here.
How about right-justifying "[Primary Method]" throughout this chapter?

2-74,5,6: Are you sure slot-boundp, slot-exists-p, and slot-makunbound
are generic?  slot-value isn't.  I guess Gregor has final say on this point.

2-85: Same comments as for 2-15.

2-90 first remarks paragraph: same comment as for 2-45.

2-92: with-slots should cross-reference with-accessors