Inheritance of Slots

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

    Date: 04 Feb 87  2349 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

Sorry about the 2-day delay in response, I've been real busy with other things
this week.

    Moon writes:

    ``Third, when compiling a method you cannot assume anything about the types of
    the slots, since a subclass could throw away your :type slot-option.''

    I guess I didn't say it clearly enough. The effective type of a slot
    is the AND (as in (AND T1 T2 ... Tn)) of the slots in the CPL. I thought
    this was exactly what this meant:

    ``{\bf :type} is constrained to satisfy all of the type constraints given
    by classes in the class precedence list.  That is, if T1, T2 and so on are
    the type constraints given by the class and all of its superclasses, the
    value of the slot must satisfy {\bf (typep value '(and T1 T2 T3...)}.''

    Didn't you (Moon) and Sonya write this?

Yes.  I was commenting on your apparent proposal to change that rule so
that the effective type of a slot depended on -only- the most specific
slot-description, when you said "If C's defclass has a slot description,
it totally shadows any other in CPL."  If you weren't really proposing
to make that change, then there is no problem.

    Moon comments:

    ``No net gain.''

    Before there were these categories of slot inheritance:

	    1. accessors and readers don't specially inherit

	    2. :allocation inherits some funny way

No, :allocation doesn't inherit.

	    3. :initform inherits some other funny way

No, the most specific :initform is used.

	    4. :type inherits by doing AND

    Now we have:

	    1. accessors and readers as above

	    2. :allocation, :initform, and :type are totally
	       inherited or totally shadowed with simple defaults.

	    3. :type constrained to be AND.

The only change is one cannot specify any slot options without
clobbering the :initform.  Nothing about :allocation or :type has
changed.  I really think it would be a bad idea to change :initform
inheritance.  Please leave it the way it is.

    ...I thought my proposal said that if you mention slot options only
    (:accessor, for example) normal inheritance happens. 

I didn't get that from reading your proposal.  If I had I would have
barfed, because that's a really strange rule.  In the slot description
list of defclass, (foo :allocation :instance) would mean something
different from (foo), because one prevents inheritance of :initform
and the other doesn't.  I would have real difficulty agreeing that
that is simple!

							 The simplified
    rule is for slot descriptions only (:allocation, :type, :initform).
    If you had :accessor only, the slot description stuff is totally
    inherited - ``the right thing.'' If you mention a slot description,
    all slot descriptions are shadowed. To be specific, the following
    statement is true:

    ...I think that the briarpatch of inheritance rules surrounding :allocation,
    :type, and :initform are too complex.

I don't disagree, but I think your suggestion doesn't make it simpler.

At the risk of repeating myself, flushing :allocation and :type would
make it a lot simpler.  So would forbidding two classes in a given class
precedence list from describing the same slot.  Short of that, I don't
see any way to make it simpler.