[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on new draft chapter 2 (dated May 16 15:09)
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
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