Re: Inheritance of Slots

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


Yes it is different in style completely.  It makes a mathematical
statement of the inheritance rules.  It is three times longer.  I don't
think it changes the intent.

    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 would be happy to get rid of :type at this point, and allow :type to
be added by the metaobject protocol using
compute-effective-slot-description.

I wouldn't mind it if one always had to (re)specify an initform if one
changed the allocation, and if allocation always defaulted to :instance
in any specification.  This would mean that you couldn't add an accessor
to :dynamic or :class slots without repeating the :allocation.  For
:class slots that would of course mean a slot in this class, as opposed
to having another way to access the one up above.  To do the latter, one
could simply use defmethod.

    		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 ..."?
I am assuming (perhaps wrongly) that the methods to access a slot would
optimize the slot access and that access to an instance slot would be
optimized very differently than access to a class slot or dynamic slot.
If this is true, then all methods that have optimized slot access will
have to be redefined.  If the underlying implementation can both
optimize and handle all three types of access, then I am wrong.