Re: Proposed revision of "Inheritance of Slots and Slot Options" section

[Danny Bobrow <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.  

SLOT IHERITANCE

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
values."

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.



  danny