Re: change-class and class redefinition

[Gregor.pa@Xerox.COM]

The first part (1-4) of this looks good.  I haven't yet had a chance to
think about the details of Restrictions on when CHANGE-CLASS can be
called or what DEFCLASS does.  I do have some comments about the first
part though.

The most important comment I have is that I would like to have the
default method on class-changed be responsible for copying over slots.
I understand that the reason you put the responsibility for initializing
the slots of the "new" instance and copying the slots in the same place
(in change-class itself) is to prevent running the :initform of slots
which already existed in the "old" instance.  Was this for efficiency or
because you preferred those semantics?  If it was for semantics, here is
an alternate proposal:

  Let change-class create a new-instance, but not call INITIALIZE on it.
Then it passes the "old" and "new" instances to class-changed.
class-changed can call initialize if it wants, or it can just copy old
slots or whatever.

My reasoning, is that I think things are more complicated when the rules
about when the various :initforms are run get complicated.  This is
reflected in my initialization protocol which has the :initforms all
being run all at once.

I like the name class-changed.  I also agree with DLW that we should
invent a term for generic-functions which you are not supposed to call
yourself.  We will need this term in the meta-object protocol chapter.
The paragraph which says that previous has dynamic extent and also says
it can be passed around needs to be re-worked.  What it says is exactly
right, its just that its confusing.  It is very important to stress that
previous has dynamic extent.