[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Inheritance of Slots and Slot Options
- To: Common-Lisp-object-system@SAIL.STANFORD.EDU
- Subject: Inheritance of Slots and Slot Options
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 11 Mar 87 00:08 EST
- In-reply-to: The message of 28 Feb 87 01:58 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Date: 27 Feb 87 2258 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
He removed the sentence:
``At most, one slot of a given name can be accessible in an instance.''
Although he inserts it later, I think it doesn't hurt to leave it where
it is (as well).
I put it back, in the revised errata I am about to mail out.
``- The type of a slot is (and T1 T2 T3...), where T1, T2, T3, and so on
are the :type slot options contained in all of the slot specifiers. If
no slot specifier contains :type, the type is t.''
Here I think the language is unclear. Does this mean that the :type option
for the most specific class is taken to be (and ...)? Is the slot
constrained to hold values that satisfy (and ...) in the sense that an
error is signaled if someone tries to store something there that does not
satisfy the type? The language we had originally stated that the :type
option defaulted to T, and the contents of the slot would always be of
type (and ...). This mimicked the language in CLtL for defstruct and
represents a statement more in line with types as optional information to
The errata sheet already contains a description of what the :type slot
option means, based on earlier discussion over the mail. What may be
confusing is that it's buried in the description of defclass in chapter 2.
I don't see a really good place to put it in chapter 1.
Later Moon writes:
``A consequence of the type rule is that the value of a slot must satisfy
the type constraint in -every- slot specifier that contributes to that
The convention in CLtL is that the phrase ``x must do y'' means that
otherwise it is an error, so we can deduce that he means that the slot is
not constrained in the sense of signaling an error.
Again, this is explained in chapter 2. In the revised errata sheet I am
about to mail out, I changed the wording of the offending sentence to be
We should probably
include at the beginning of these chapters a warning to read page 6 of
CLtL to understand the conventions of the language we use.
I agree, it wouldn't hurt to say that we are using the same terminology
as CLtL in the next version of this document.
Moon writes in the next paragraph:
``An argument to a method can be an instance of a subclass of the class
declared by a parameter specializer, so the compiler cannot know the exact
This should be expanded because many will not easily see the connection
between random methods and optimizing based on the types of slots.
Instead, I removed the whole discussion. It seems either a whole page of
design rationale is needed here, or it's better simply to state how it is
without trying to explain why.
The strong type constraint rule Moon proposes
Please note that I never proposed this, I only tried to make the explanation
understandable. If I had my druthers, there would be no :type slot option.
has some effects that might
be difficult for a reader to understand unless explained properly. Suppose
(defclass c1 () ((foo :type t1)))
(defclass c2 (c1) ((foo :type t2)))
(defclass c3 (c1) ((foo :type t3)))
The FOO slot in C1 must be of type (and T1 T2) when regarded from the
point of view of C2, and it must be of the type (and T1 T3) when regarded
from the point of view of C3. Therefore, it actually must be of type
(and T1 T2 T3). The compiler compiling methods on C2 or C3 alone won't care
much, and when it compiles a method on C2 and C3 it might discover the happy
fact. A reader of this specification might be confused into thinking that
there is some intractable problem at hand and that the type of a slot cannot
actually be deduced because it depends on classes very far away.
Your last sentence here was what really convinced me that it was better not to
try to explain the design rationale here. I removed all mention of compilers.
Moon writes near the end:
``The :reader and :accessor slot options were not mentioned above because
they create methods rather than defining characteristics of a slot.
Reader and accessor methods are inherited in the sense described in the
section ``Inheritance of Methods.'' ''
This needs to be made clear at the outset: two-pass reading is bad
I agree; I moved this up to a more appropriate place.