[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed revision of "Inheritance of Slots and Slot Options" section
- To: Common-Lisp-Object-System@sail.stanford.edu
- Subject: Re: Proposed revision of "Inheritance of Slots and Slot Options" section
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 11 Mar 87 00:10 EST
- In-reply-to: <870227-162043-4596@Xerox>
Date: 27 Feb 87 16:20 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
In general I agree with Moon that slot inheritance is simple and like
his rewording. A few minor glitches:
If the :allocation slot option is omitted or specifies a local
slot, then each instance of C stores its own value for the slot.
This needs to be specific about local being either :instance or :dynamic
(or perhaps it should have that earlier).
An earlier item on the errata sheet was to add :dynamic where it had been
left out. But I agree that it's better to mention the specific keywords
here too, so I added that to the revised errata sheet I am about to mail
Secondly, the type constraint is presented very strongly. The intent of
having it (I pushed it in) was to allow compatibility with current
defstruct. Current defstruct does not specify that a slot MUST meet its
type constraint. Consequently, I would suggest that the rule specify:
"The :type of a slot need not be specified. If it is, the
interpretation is that the value of the slot should be of type (and T1
T2 T3...), where T1 , ... Tn are all the type specifiers provided in any
slot specifcation. Implementations need not check for values, but those
that do should use the interpretation, and hence may optimize for those
In 87-002 it seems we forgot to say anywhere what :type really means.
The errata sheet for chapter 2 says something that I think is equivalent
to what you just said.