Re: Redefining Classes

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

After reading Patrick's message, and some more thought, I now agree with
Moon's paragraph.  I am even willing to believe that common slots
(retained slots) maintain their bit contents (unbound slots are not
initialized by the updating). I have rewritten Moon's paragraph using
Patrick's suggested name change:
     When redefining a class causes instances to be updated can be
     implementation-dependent.  The user extendible generic function 
       (update-instance-structure instance added-slot-names
               removed-slot-names removed-bound-slot-values)
     is called to complete updating of the instance structure; its
     primary method uses initforms to initialize the slots whose names
are
     listed in added-slot-names.  update-instance-structure is called no
     later than the first slot read or write of that instance after the
     class is redefined. The retained slot values are already in place
when
     update-instance-structure is called.

There is still the open problem of (re)initialization of class variables
on redefinition.  More thoughts???

Patrick asked:
    Shouldn't CHANGE-CLASS & CLASS-CHANGED changed the same way for
    the same reasons?

I believe that update-instance-structure and class-changed should be
comparable.  I will send out a revised writeup.  I agree with the
general principle reiterated by Patrick, and strengthened here:
    No user should ever get hold of a value coming from a
    non-updated instance.