[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Chapter 1 and 2 Last Chance Review
- To: pierson%mist@MULTIMAX.ARPA
- Subject: Chapter 1 and 2 Last Chance Review
- From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 13 Apr 88 17:12 EDT
- Cc: common-lisp-object-system%sail.stanford.edu@MULTIMAX.ARPA
- In-reply-to: <8804132019.AA00841@mist.UUCP>
Date: Wed, 13 Apr 88 16:19:19 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Comments on Chapters 1 and 2 of the CLOS Spec (Edition of 2/8/88)
Hey, you actually read it! Thanks for the useful comments.
Page 1-9, Add to the list of things provided by slot options and
o Specifying the legal data types of the slot contents.
(Of course, this can be found elsewhere in the document,
but my impression on reading this introductory list was
that for some reason you couldn't do this.)
Good idea. (I think originally this section was intended to be an
overview of the more interesting features, but eventually all of the
features got added except for the :type constraint.)
Page 1-11, Paragraphs 3 and 7
Why are reader, writer, and with-slots *required* to be
implemented using SLOT-VALUE? I don't doubt that you have
a good reason, but it's not obvious to a relative novice.
Some background is: we know that any implementation of CLOS will have
to have a primitive that does what SLOT-VALUE does. Otherwise you
couldn't implement readers or writers at all. So we document that
primitive (SLOT-VALUE) so that all implementations give it the same
name, arguments, and behavior, and therefore users can write portable
code that calls it. The goal is to expose the underlying mechanisms
if they are generally useful.
The purpose of WITH-SLOTS is just to be a shortcut syntax for using
SLOT-VALUE all over the place. It's "required" to be implemented with
SLOT-VALUE because that's just the definition of what it does.
As for why readers and writers are "required" to be implemented using
SLOT-VALUE, hmmm, I'm not sure. I don't think there's any reason why
you wouldn't implement readers and writers with SLOT-VALUE, since
SLOT-VALUE does the thing you want to do.
Paragraphs 7 and 8
This implies that WITH-SLOTS can access slots without
accessors but WITH-ACCESSORS can't. This is reasonable
but should probably be made explicit. Some people may
feel that this maked WITH-SLOTS unsafe.
The implication was intended; that's the difference between the two
macros. I personally agree with people who feel WITH-SLOTS is unsafe.
We could add a sentence to imply what we mean more directly.
Page 1-13, Paragraph 4
This paragraph appears self-contradictory. I think that
it means that portable code cannot depend on slot types
(1) Some implementations may not provide type errors
(therefore reducing the value of slot types for
Yes, it does mean (1). This is also said in the first bullet on page
(2) Calls from outside the package may store incorrect
types (so even if your portable code is self-consistent
you could wind up with undetected type errors).
I don't know what you mean by (2).
The wording of this paragraph leads me to suspect that
this issue has already been argued to death on the CLOS list.
(Don't let the wording fool you. We argue every issue to death.)
Page 1-26, Paragraph 2, Sentence 2
The following are my exact notes as I read this section:
What about methods in both old and new? Are they "added"?
If so, in what way is this definition different from
saying that the "contents" of the old generic function are
trashed and replaced by the new generic function? AHA!
Some methods could have been defined by DEFMETHOD, but the
wording is still confusing.
Your point about "some methods could have been defined by DEFMETHOD" is
correct, and we should probably add a sentence to that effect.
Page 1-32, At this point I made a note:
In general, this draft details the complex, general case
before the simpler, common special case.
The section in page 1-32 doesn't present the simpler, common special
case first and then get into details that include the hairy, rare cases.
It does all cases at once. This is a very central part of CLOS, and
it is somewhat complex, so readers are going to have to read the section
on Method Selection and Combination a couple times or more. I think
it's OK as it is.
This *may* be
appropriate for a standards document but it certainly
isn't for a manual.
Right. Manuals have a lot more freedom.
Page 2-27, Next to last paragraph
Can extension slot options appear more than once in a
single slot description (it appears reasonable, but it's
not clear from this whether it's legal).
The slot can also be accessed by WITH-SLOTS, since
WITH-SLOTS uses SLOT-VALUE.
Do you think we need to say that explicitly? Since WITH-SLOTS is
defined in terms of SLOT-VALUE, I think most readers will figure this
out, as you did.
Page 2-35, Paragraphs 7 and 8
These paragraphs don't specify how to distinguish a
predicate from the first keyword option since they are
both distinguished by being symbols other than * (or NIL).