Re: Class Redefinition

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

rpg says
    It would be nice if different classes weren't EQ. Is there no
    way to make this work?
The problem is what is a different class.  People build networks of
objects, including classes.  The point of the spec is that these
networks (including the one in the class lattice) should have to change
when a class is changed.   People do not always refer to classes by
names.

Response to Moon:
  
Although I have not thought about it a lot, I think Moon's refinements
GET-CLASS-FOR-NEXT-REDEFINITION
and
GET-OBSOLETE-CLASSES
  seems fine.  I don't understand the experience of why one gets into
trouble making CLASS-CHANGED methods after redefinition as Moon says,
but perhaps it is because I am not working in a true multi-process
system.  

I think we have only two choices with respect to methods applicable to
obsolete instances--
1) All methods applicable to the class itself i.e. the obsolete-class is
a subclass of the new class
2) Only slot-value-using class.

A problem with the first is what happens if a method is removed from a
class before an obsolete instance is converted to a real instance.  For
example, in the famous rho-theta example, suppose we have x-y points
(ones with x and y as slots), and decide to change class to store only
rho and theta.  Then after redefining the class, a naive user might 

1) build a class-changed method that used the methods for rho and theta
for conversion
2) believe that these rho and theta methods could be removed from the
rho-theta-point class.

In this description I have made it obvious why this is wrong.  But
suppose this were a case where both of generic functions for rho and
theta used another routine that was no longer needed.  The user might
easily delete that one. 

I think that it might be better to go to 2, though clearly it makes
class-changed have a lot less easily accessible power.