Should redefining a class reinitialize shared slots?

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

    Date: 29 Sep 87 08:59 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

	I haven't been able to figure out what you mean here.  Editing
	out the parts of your comment I don't understand leaves "Redefining
	the class should set the value of the class slots", which we've
	never said before and I don't think I agree with.  Here are two
	cases to think about:
	(1) A class slot whose value is a list of all the instances,
	initialized to nil when the class is first defined and updated by
	an initialize-instance method.
	(2) A class slot whose value is the price of an instance,
	initialized by :initform in the defclass.
	In case 1, you surely don't want the slot value reset to nil
	when you redefine the class.  In case 2, you might want to set the
	price to the new value of the :initform.  If redefining a class
	always reinitializes class slots, you can't do case 1.  If it never
	reinitializes class slots, you can work around case 2 by doing setf
	of slot-value at the same time as you redefine the class.

    These are interesting examples, and cause one to ponder.
    I think the difference here is like the difference between 
      editing a function definition on a file and 
      editing the actual function list structure with a structure editor. 
    Changing a function using a structure editor affects existing calls, and
    editing the file cannot.

I think that's a good analogy.

Although, which existing calls are actually affected by changing a function
with a structure editor probably depends a lot on what in the function you
change, versus where in the function control is suspended, and also on
implementation-dependent details such as whether you compile or not.
Maybe that's part of the applicability of the analogy, though, in the
sense that the issue never seems to be simple.  Bring back APL\360, where
editing a function automatically invalidated any activation records for
that function, and announced "SI DAMAGE".

    I think the corresponding cases for classes are: 
      use the metaobject protocol to update an existing class using the slot
       objects that currently exist, 
      and reevaluating the defclass form.
    In the latter case, the specification only guarantees that class
    objectsame object identity is preserved, 

Well, what the specification actually says (87-002 page 1-12, very top
of the page, sentence actually starts on the preceding page) is that
values of class slots are preserved.  So the issue is whether we want
to change the specification.  I think the specification now says that
re-evaluating a defclass form is not like re-evaluating a defun form,
but is more like structure editing: it patches an existing object
rather than creating a new object.

					     unless we want to go more into
    a DWIM mode, that is guess which items in the new definition are meant
    to yield the same result as the old case.

The DWIM idea doesn't appeal to me since I can't figure out how to make
it predictable.

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.

Revisiting in this light the rules for slots whose allocation is changed:

class -> instance copies the slot value into each instance, again
by analogy with the rule for instance slots (the value returned
by SLOT-VALUE remains the same).

instance -> class reinitializes the slot, because there is no
distinguished instance from which to get the value.