[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redefining Classes
- To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- Subject: Re: Redefining Classes
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 29 Sep 87 22:45 EDT
- In-reply-to: <2768937098-6088589@Jenner>
Date: Tue, 29 Sep 87 16:11:38 CDT
From: Patrick H Dussud <DUSSUD%Jenner%csl.ti.com@RELAY.CS.NET>
Date: Mon, 28 Sep 87 22:18 EDT
From: "David A. Moon" <Moon@scrc-stony-brook.arpa>
For these reasons, I believe it is better to specify that the
slot values are conveyed from the old structure of the instance to
the new structure by the low-level implementation, not by a
user-replaceable method. Thus when the generic function
update-obsolete-instance is called, all slots that existed in the
old class definition, and existed as instance slots in the new
class definition, already have their values, as the same low-level
bits. I can't see any need for even a meta-user to replace this
with something else.
Shouldn't CHANGE-CLASS & CLASS-CHANGED changed the same way for the same
This is not a problem. Since at least March, CHANGE-CLASS has been
documented to convey the slot values before it calls CLASS-CHANGED.
One inconsistency remains: CHANGE-CLASS initializes the newly added
slots from their initforms before calling CLASS-CHANGED, whereas
class redefinition initializes the newly added slots in the default
primary method for UPDATE-OBSOLETE-INSTANCE, last I heard. We probably
ought to make them both work the same way.
I prefer not to put this into a method, because then we have to say
what is the state of those slots when a :BEFORE method is running.
I prefer to have the instance in a completely consistent state before
the user-specializable generic function is called. Others prefer to
put it into a method so it can be replaced with something else. Is
that something people actually would do?