[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed revision of "Inheritance of Slots and Slot Options" section
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: Proposed revision of "Inheritance of Slots and Slot Options" section
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 27 Feb 87 16:20 PST
- Cc: Common-Lisp-Object-System@sail.stanford.edu
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of NIL
- Sender: Bobrow.pa@Xerox.COM
I am now back from my trip so I will try to comment on some of the
relevant messages in my absence.
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).
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
And then one could add the following from Moon's suggestion.
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 slot. This maximally restrictive rule allows a
compiler to optimize on the basis of the :type slot option. 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 class.