[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: 13 Apr 88 11:15 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
(6) Why do the four updating functions have such inconsistent
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.
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.