Inheritance of Slot Options

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

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

    I think the current spec suffers from excessive rules for the sake
    of marginal functionality. I propose this slight modification:

    We break what was slot options into two categories, slot descriptions
    and slot options (in the BNF, what was ``slot options'' becomes ``slot
    descriptor''). Slot options are the :accessor and :reader guys. Slot
    descriptions are :initform, :allocation, and :type. The slot options
    are as before. Slot description inherit like this:

    Let CPL be the class precedence list for C. If C's defclass doesn't have a
    slot descrption for a slot it is totally inherited from the next most
    specific class in the CPL. If C's defclass has a slot description, it
    totally shadows any other in CPL. When this latter case happens, some of
    the aspects of the slot description might be defaulted. The defaulting is
    as follows:

	    :initform is defaulted to unsupplied
	    :allocation is :instance
	    :type is T

    The effective type of a slot is the AND of all types specified for it
    in the CPL.

    There are two differences between this and the previous rule (which I now,
    unfortunately, understand). First, :initform acts differently - if you want
    to change the :type or :allocation and keep the :initform, you have to mention
    the :initform again. Second, it is an easier rule to understand and remember.

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.
As far as I can tell this would make it impossible to use :type for anything,
certainly it seems to rule out the use you (Dick) mentioned for it when it
was first proposed.

    I think it's counterproductive to have a complex set of rules to enforce
    some intuition that doesn't pay its own way. A simpler but slightly inaccurate
    model, where the inaccuracy to someone's intuition is unimportant, is
    preferrable to a complex model that captures someone's epicycle.

These rules don't really seem any simpler to me.  The concept of looking at
every slot-option in the class precedence list is no different from the concept
of looking at every method in the class precedence list; that concept has been
simplified out, but the concept of slot options and slot descriptions being
two different things has been added.  No net gain.

In addition, I'm not happy about the idea that one cannot define an :accessor
for an inherited slot without clobbering its :initform.  This seems just plain
wrong.  It's a symptom either of your proposal not being right or of the whole
defclass syntax not being modularized properly.