# Re: Amendments requiring additional writing

• To: Moon@STONY-BROOK.SCRC.Symbolics.COM
• Subject: Re: Amendments requiring additional writing
• From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Date: 29 Sep 87 08:59 PDT
• Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
• In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Mon, 28 Sep 87 18:43 EDT
• Sender: 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
(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 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, 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.

If in the new version of the class there is a shared slot of
the same name as any local slot in the old version of the class,
that shared slot is initialized to the value of the corresponding
{\bf :initform} option of the new class, or remains uninitialized
if the new version of the class does not specify or inherit the
{\bf :initform} option for that slot.  Shared slots are not
affected by the updating of an instance.

This again seems mistaken for me.  What value should go
in the new shared slot -- that is, from which particular
instance will it be set.

You didn't read what I said, which is that the new shared slot
is initialized from the initform, not from any particular instance.
That indicates that what I wrote wasn't written clearly enough.
You are right.  I didn't read well enough.  Your text is correct.

danny