Inheritance of Slot Options

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

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.

				-rpg-