Re: Amendments requiring additional writing

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

    Date: 28 Sep 87 13:34 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    A slightly modified version of Moon's pararaph to remove references to
    change-class

       1-11: Replace the last paragraph with the following two paragraphs:

	If in the new version of the class there is an instance slot of the
	same name as any slot in the old version of the class, the value of
	that slot will be the same in both instances.  This means that if
	the slot has a value, the value returned by {\bf slot-value} after
	the class is redefined {\bf eql} to the value returned by {\bf
	slot-value} before the class is redefined.  Similarly, if the slot
	was uninitialized, it remains uninitialized.

You're right, I spazzed in editing and shouldn't have copied those
references to change-class from the old text.  Oh, wait, it wasn't
an editing spazz, I said a bit later in the message that I was just
finishing up the amendments from last March and not trying also to do
all the rewriting of the document to suit our latest mind changing.
However I agree with the new wording, except for the typo you
introduced (missing "is").

On the issue of whether we say "class slot" or "shared slot", I do not
have an opinion.  It would be nice if we could work out the wording of
this part of the document without doing a lot of switching back and
forth on that terminology, though; we could fix the terminology
afterwards.

    This is fine so far.  But the following is problematic.

	At the moment a class is redefined, if the new version of the
	class contains a shared slot of the same name as any shared slot in
	the old version of the class, the value of that slot will be the
	same in both. 
 
    Should this be true?  Will changing the context of the defclass form not
    effect the value of the class slot.  I think this is a mistake.
    Redefining the class should set the value of the class slots, and
    whether that value is EQL or not must depend on the evaluation form and
    context.

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.

    I also have a problem with:

	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.

    I think the correct paragraph would read:

	If in the new version of the class there is a class slot of the
	same name as any instance slot in the old version of the class,
	that class slot is initialized by the redefinition of the class,
	and is not affeced by the value of any slot in any of the
	instances.  

The last two lines are the addition here, and it seems like a good idea
to bring this out very explicitly.  I don't know that it was necessary
to remove the definition of what it means for a slot to be initialized
by the redefinition of the class.

		    If there is an instance slot in the new definition of
	the class that is the same name as a class slot in the old version
	of the class, then on updating, the value of each instance slot is
	given the same (EQL) value as the that in the old class slot.  If
	the class slot in the old version of the class was uninitialized,
	then the instance slots in the new instances are initialized as if
	they were new slots in the instance.  

This was already covered by the first paragraph, which evidently needs
to be made more explicit that when it says "the same name as any slot"
it means any slot, including both class and instance slots.  However,
I don't agree with your last sentence.  I think it's much simpler to say
that uninitialized slots remain uninitialized, regardless of the allocation,
rather than to make a special case for slots that are both uninitialized
and switching from class allocation to instance allocation.

Maybe a more succinct way to say this is that if you really want to
reinitialize a slot, you should remove it and then add it back.
Actually, though, now that we got rid of the sequential class
redefinition idea, that doesn't work unless you contrive to update
every instance before redefining the class the second time.  I
shouldn't be surprised that one has to give up a few things when
adopting the simpler scheme.

Looks like we need a couple more iterations on the writing of this
couple of paragraphs.