Re: Redefining Classes

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

    Date: Tue, 29 Sep 87  16:11:38 CDT
    From: Patrick H Dussud <DUSSUD%Jenner%csl.ti.com@RELAY.CS.NET>

         Date: Mon, 28 Sep 87 22:18 EDT
         From: "David A. Moon" <Moon@scrc-stony-brook.arpa>
     
         For these reasons, I believe it is better to specify that the
         slot values are conveyed from the old structure of the instance to
         the new structure by the low-level implementation, not by a
         user-replaceable method.  Thus when the generic function
         update-obsolete-instance is called, all slots that existed in the
         old class definition, and existed as instance slots in the new
         class definition, already have their values, as the same low-level
         bits.  I can't see any need for even a meta-user to replace this
         with something else.

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

This is not a problem.  Since at least March, CHANGE-CLASS has been
documented to convey the slot values before it calls CLASS-CHANGED.

One inconsistency remains: CHANGE-CLASS initializes the newly added
slots from their initforms before calling CLASS-CHANGED, whereas
class redefinition initializes the newly added slots in the default
primary method for UPDATE-OBSOLETE-INSTANCE, last I heard.  We probably
ought to make them both work the same way.

I prefer not to put this into a method, because then we have to say
what is the state of those slots when a :BEFORE method is running.
I prefer to have the instance in a completely consistent state before
the user-specializable generic function is called.  Others prefer to
put it into a method so it can be replaced with something else.  Is
that something people actually would do?