Re: Should redefining a class reinitialize shared slots?

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

    Date: 30 Sep 87 17:30 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

	It seems to me the only predictable rules are: (1) all
	class slots retain their values when the class is redefined. (2)
	all class slots are reinitialized when the class is redefined.

	I prefer rule 1 because it is analogous to the rule for
	instance slots. Also, it's easier to reinitialize a slot that was
	retained than to retain a slot that was reinitialized, if a user
	wants to implement behavior different from the default.

    Despite the fact that I think I would usually want to retain current
    values of class slots, I worry about a confusion of models for the user.
    Rule 2 is a pure text based model; Rule 1 is a semi-structural model.
    This leads to questions about what changes in a class slot cause it to
    get reinitialized?

    If I change the :type 
    If I change the :initform 
    If I change its order in the list of slots  
    If I add another class slot before it in the list
    If I change its name  

    If one were doing structural editing, then none of these would cause
    reinitialization (even a name change).  When dealing with the defclass
    form as text, the answer is less clear -- even with respect to the name
    change i.e.  consider changing to "all-instances" from
    "all-my-instances" or from "allinstances".

The rule that CLOS has been using all along is that slot identity is
determined entirely by the slot's name.  It seems to me that this is
visible in many places throughout CLOS.  This means that the only edit
that causes a class slot to get reinitialized is changing its name 
(it's not really meaningful to say the slot gets reinitialized in this
case; rather, one slot is deleted and a new one is created and initialized).
Changing any other attribute of the slot does not affect the slot's
identity (with the one unfortunate exception that changing the allocation
from instance to class (a.k.a. from local to shared) destroys the slot
and creates and initializes a new slot).

I think bringing in notions of editors of various types may actually only
confuse the issue.  After all, the semantics of classes in CLOS are defined
in terms of the behavior of certain objects under certain operations, and
are not tied to the syntax of the DEFCLASS form, right?  DEFCLASS is only
the most convenient way to define a class, not the only way.

	I prefer rule 1 because it is analogous to the rule for
	instance slots. Also, it's easier to reinitialize a slot that was
	retained than to retain a slot that was reinitialized, if a user
	wants to implement behavior different from the default.
    I find these arguments strong, but still find rule 2 is most consistent.
    Rule 1 probably is desirable in most cases, but I think will be
    confusing when we consider the above cases -- again, shades of DWIM.  My
    intuition is not strong on this, so I would like to see opinions from
    Gregor and Patrick (others too, of course).

I vehemently disagree with the notion that rule 2 is consistent with the
rest of CLOS.

	I prefer rule 1 because it is analogous to the rule for
	instance slots. Also, it's easier to reinitialize a slot that was
	retained than to retain a slot that was reinitialized, if a user
	wants to implement behavior different from the default.
  
    RPG writes:
	There is a third option, which would be to specify the
	redefinition initialization action in the DEFCLASS as a class slot
	option (:retain or :reinitialize, for example).
    I don't think additional language features are useful here; in
    particular, I would hate to see options specified that depended on the
    value(s) of other option(s).  I think we must make up our mind what
    model to be supported.   

I agree with this.  We should only adopt this third option if it becomes
clear that it solves problems that we need to solve and that neither of
the other two options can cope with.