[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on chapter 2, through defgeneric
2-6: This hasn't changed from 87-002, but I find the way the value of
add-method is described confusing. It isn't made perfectly clear
that the value is always eq to the first argument, rather than being
a copy of it with modifications. I'd prefer to write
"Values: {\it generic-function} is returned."
Compare the way it's done for change-class on 2-10, which is unambiguous,
but a little verbose.
================
2-7: The text that was in the previous version saying that the name
CALL-NEXT-METHOD only has a function definition within the lexical
scope of a method body got lost. We have to say something about this.
I think the most reasonable thing might be that outside the lexical
scope of a method body, CALL-NEXT-METHOD designates a function that
signals an error if called. We also have to say whether the lexical
scope of CALL-NEXT-METHOD includes forms in a method's lambda-list.
I prefer "yes", because in Flavors it used to be "no", and several
users complained so we had to change it. The implementation is
slightly more difficult, but only very slightly.
================
2-7 second Arguments paragraph: In one place this says an error is
signalled, in another it says the results are undefined, when bad
arguments are passed to call-next-method. Which is right? I don't
remember for sure but my notes from the the most recent meeting
indicate "signals an error." Also, the last sentence on this page
belongs in this paragraph, not in the paragraph that it is in.
================
2-11 last paragraph: This never says what the problem being compounded
is. It's that after changing the class of an argument, the methods
now executing or about to be executed might no longer be applicable.
================
2-20: the description of the slot options is a bit inconsistent about
whether it calls them "options" or "slot options". The introductory
phase for all but :initarg says just "option". I think I'd prefer
saying "slot option" everywhere when discussion slot options, although
that can get a bit verbose. In any case the style should be made consistent.
================
2-20 first bullet: "the setf generic function named generic-function-name"
should be "the generic function named (setf generic-function-name)".
================
2-20 last hyphenated bullet, last sentence: What it says here is slightly
oversimplified. If a class C1 defines a shared slot named S, a subclass
C2 can avoid sharing S without itself containing a slot specifier for S
in its defclass form, if C3 is a superclass of C2, C3 contains a slot
specifier for S, and C3 precedes C1 in the CPL of C2. There is probably
a clearer way to say what I just said.
================
2-21 second bullet: "The expression (typep value value-specifier) will
be true for the value stored in the slot" doesn't conform to the error
terminology introduced in chapter 1. I think we mean something like "If
the expression (typep value value-specifier) is not true for the value
stored in the slot, the results are undefined" but maybe this needs to
be phrased differently to clarify that what is undefined is for a program
to perform an action that would cause that expression to become untrue.
Also clarify that the type check does not apply to an uninitialized slot,
since such a slot does not have a value at all.
================
2-21: Just a reminder to everyone that the constructor writeup here is
not what anyone is proposing. It is neither exactly my proposal, nor
of course is it the null proposal. I presume we're letting it be until
we agree on what to do.
================
2-22 last bullet: remove this, with-slots no longer depends on the
class definition.
================
2-22 2/3 down the page: Change "No class options are inherited" to
"No class options except :default-initargs are inherited".
================
2-22 third paragraph from the bottom: "the initial value of the slot
is unspecified": this is incorrect. Change the phrase to "the slot
is uninitialized".
================
2-22 second paragraph from the bottom: :initarg can also appear more
than once in a slot description.
================
2-22 last paragraph: :default-initargs can also appear more than once in
a defclass.
================
2-24 fourth paragraph: The calls to fboundp and symbol-function are
missing quote marks. In the second sentence, new-value should be in
italics, not bold. Can this be rephrased to avoid introducing the term
"setf generic function"? Perhaps this paragraph could be merged into
the second paragraph, simply saying that -name- can be a symbol or
a setf-list. Then the fboundp/symbol-function rules wouldn't have to
be stated twice.
2-24 I'm not sure I understood the double square bracket notation used
in this chapter, but it appears to be saying that defgeneric is only
allowed one option. Maybe this is just a typo of a missing asterisk?
But maybe the syntax could be simplified by making -method-description-
a subcase of -option-. I'm not sure that -method-specifier- needs to
be a separate syntatic nonterminal symbol; why not merge this into
-method-description-?
2-24 I'd prefer not to have separate syntax for lambda-list and setf-lambda-list,
since this requires the reader to study them to figure out what is different.
It would be better to use one syntax and say in text that the new-value is
the first required argument (and therefore there must be at least one required
parameter). Affects 2-26 fifth paragraph, 2-28 fourth paragraph too.
2-24 I'm not sure we want to allow the (var) form for an optional parameter
specifier in defgeneric. The 87-002 document was ambiguous here, but I had
read it as allowing only a symbol as an optional parameter specifier, so I
was surprised to see that the other form was being allowed now too. Similarly
for keyword parameter specifiers, I would allow var and ((keyword var)), but
would forbid (var). The (var) forms seem to me likely to mislead someone
into thinking that default value forms are permitted here. I admit this is
a matter of taste.
2-25 last line: (eql -object-) should be (eql -form-) since -form- is
a form that gets evaluated at the time the defgeneric is evaluated, and
the value of -form- is the object that an argument has to be eql to to
satisfy the parameter specializer. Appears again on 2-27 fifth bullet.
2-26 discussion of optimize declaration: change "defmethod form" to
"defmethod form or method-description".
2-27 "specialized-setf-lambda-list" is mentioned here, but is not in the syntax.
It can be removed.
================
TYPOS:
2-20 last bullet: ":initform argument" should be ":initform slot option",
in two places.
2-22 first Remarks paragraph: remove the reference to change-class.
2-28 second Remarks paragraph: "a anonymous"