[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inheritance of Slots
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: Inheritance of Slots
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 10 Feb 87 15:10 EST
- In-reply-to: <870210-104034-6948@Xerox>
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,
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 ..."?