Re: Reinitialization

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

    Date: 13 Apr 88 11:15 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

	(6) Why do the four updating functions have such inconsistent
	interfaces?....
	so the real issue is why don't class-changed and
	update-instance-structure take similar arguments?

    We decided that there was no reasonable way to specify what it meant to keep
    around a copy of an obsolete-class and its methods, and therefore we had to use
    the list descriptions of the old instance.

    On the other hand, for class-changed, the methods and classes are current. Hence
    it is reasonable to leave in the users hands the problem of keeping the method
    for class-changed current.

Oh, right.

Suppose that instead of its present arguments, update-instance-structure
took an old-instance and a new-instance, where the old-instance was of
an old-class that was a direct subclass of the class being redefined.
old-instance and old-class have dynamic extent.  Suppose further that
old-class has no methods of its own, so exactly the same methods are
applicable to old-instance as are applicable to new-instance (barring
bizarre use of methods on individuals).  If we do this, then in the
rho/theta/x/y example, you can't use accessor methods to get the old
information, just as you can't use accessor methods now.  The difference
is that an update-instance-structure method would use slot-value to
get the old slot values, and would use normal chapter 3 facilities to
find out what slots were added and removed, instead of getting that
information in an idiosyncratic way.

I think a change like that would make the language a little more
consistent.  However, I don't feel strongly about it, as even with
that change there would still be no shortage of minor inconsistencies.