initargs and change-class

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

    Date: Mon, 11 Jun 90 22:55:13 PDT
    From: Gregor J. Kiczales <gregor@parc.xerox.com>

    It appears that we never made the change to have change-class and
    update-instance-for-redefined-class accept initialization arguments.
    We should do this, a number of people have asked for it, it is
    consistent, simple, and provides an elegant way to pass information
    about why the class is being changed.

Of course you really mean update-instance-for-different-class, not
update-instance-for-redefined-class, or do you have some way to get
initialization arguments passed through to the automatic calls to
update-instance-for-redefined-class that happen when an obsolete
instance is touched?

Both update-instance-for-different-class and
update-instance-for-redefined-class already accept initialization
arguments, so the only issue is change-class.  I don't see any harm
in adding initialization arguments to change-class and having it
pass them through.

    In fact, it seems (to me at least) that this is just something we forgot
    to do before rather than a real decision we made not to do it.

I don't remember it ever being discussed.  At this point we need to go
through a formal change process even if we claim we forgot, since the
CLOS specification has been published in numerous places, translated
into Japanese, engraved on the side of a space probe launched to Mars,
etc.  It is technically an incompatible change since all user-defined
methods for CHANGE-CLASS will get congruency errors after the change is
made.  However, I would have been in favor if you had proposed it last
week.