Re: Inheritance of Slots

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 10 Feb 87 10:38 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    I read the current document last night and was appalled at the
    complexity of the rules that were used to explain the inheritance of the
    characterisics of slot-descriptions.   

Is this before or after Dick's venture at improving the way it's
described?  The hardcopy I have (from Jan 31) doesn't look extremely
complicated, certainly less complicated than earlier attempts.  The
English does need to be cleaned up a bit to make it crystal clear,
though.

I think it's fundamentally complicated, because :initform, :allocation,
and :type have been specified by the group to work three different ways,
and changing any one of them to work the same as another breaks
something.  My opinion is that the only way to simplify it would be
to get rid of some features.

					   I also realized that accessors
    and readers MUST be inherited.  A new method need not be built for every
    class if the implementation guarantees that the method inherited still
    works.  But whenever there is a change of the :allocation
    characteristic, every accessor and reader in the inheritance chain must
    have a new method created for it.

I don't believe this is true.  Could you specify some reasons why new
methods would have to be created?  And do those reasons mean that the
following will not work?

(defclass c1 () (s))
(defclass c2 (c1) ((s :allocation :class :initform 1)))
(defmethod foo ((self c1)) (with-slots (self) (print s)))
(foo (make-instance 'c2))

How does this relate to the remark in the inheritance section
"Methods that access slots know only the name of the slot and
the type constraint ..."?