[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Amendments requiring additional writing
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: Amendments requiring additional writing
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 28 Sep 87 13:34 PDT
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Fri, 25 Sep 87 21:41 EDT
- Sender: Bobrow.pa@Xerox.COM
A slightly modified version of Moon's pararaph to remove references to
change-class
1-11: Replace the last paragraph with the following two paragraphs:
If in the new version of the class there is an instance slot of the
same name as any slot in the old version of the class, the value of
that slot will be the same in both instances. This means that if
the slot has a value, the value returned by {\bf slot-value} after
the class is redefined {\bf eql} to the value returned by {\bf
slot-value} before the class is redefined. Similarly, if the slot
was uninitialized, it remains uninitialized.
This is fine so far. But the following is problematic.
At the moment a class is redefined, if the new version of the
class contains a shared slot of the same name as any shared slot in
the old version of the class, the value of that slot will be the
same in both.
Should this be true? Will changing the context of the defclass form not
effect the value of the class slot. I think this is a mistake.
Redefining the class should set the value of the class slots, and
whether that value is EQL or not must depend on the evaluation form and
context.
I also have a problem with:
If in the new version of the class there is a shared slot of
the same name as any local slot in the old version of the class,
that shared slot is initialized to the value of the corresponding
{\bf :initform} option of the new class, or remains uninitialized
if the new version of the class does not specify or inherit the
{\bf :initform} option for that slot. Shared slots are not
affected by the updating of an instance.
This again seems mistaken for me. What value should go in the new
shared slot -- that is, from which particular instance will it be set.
I think the correct paragraph would read:
If in the new version of the class there is a class slot of the
same name as any instance slot in the old version of the class,
that class slot is initialized by the redefinition of the class,
and is not affeced by the value of any slot in any of the
instances. If there is an instance slot in the new definition of
the class that is the same name as a class slot in the old version
of the class, then on updating, the value of each instance slot is
given the same (EQL) value as the that in the old class slot. If
the class slot in the old version of the class was uninitialized,
then the instance slots in the new instances are initialized as if
they were new slots in the instance.