Amendments requiring additional writing

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Here is a replacement for pages 1-11 and 1-12, based on the referenced
mail and the latest CONCEP.TEX on SAIL.  I offered to write this because
it incorporates an amended paragraph I sent out on 25 Sep, and because
Danny asked me to write it because he said he was too busy to do any
writing.

Note that we will probably want a separate section explaining how to
change the class of an object, using change-class.  Note that
class-changed and update-instance-structure are currently incompatible
with respect to who evaluates the initforms; one of them has to be
changed.   I didn't attempt to write anything for change-class.  We
could always describe change-class only in the Function chapter, and
not have a Concept section for it.

I have not changed any local/shared/instance/class slot terminology.
We can change that later if we agree on the new terminology.


\beginSection{Redefining Classes}  

When a {\bf defclass} form is evaluated and a class with the given
name already exists, the existing class is redefined.  Redefining a
class modifies the existing class object to reflect the new class
definition; it does not create a new class object for the class.  Any
method created by an {\bf :accessor} or {\bf :reader}
option specified by the old
{\bf defclass} form is removed from the corresponding generic
function unless that same method is specified by the new {\bf
defclass} form; any function specified by the {\bf :constructor}
option of the old {\bf defclass} form is removed from the
corresponding symbol function cell.

When the class $C$ is redefined, changes are propagated to instances
of it and to instances of any of its subclasses.  The updating of an
instance whose class has been redefined (or any of whose superclasses
have been redefined) occurs at an implementation-dependent time, but
no later than the next time a slot of that instance is read or written.
Updating an instance does not change its identity as
defined by the {\bf eq} function.  The updating process may change the
slots of that particular instance, but it does not create a new
instance.  Whether updating an instance consumes storage is
implementation dependent.

If a class is redefined in such a way that the set of local slots
accessible in an instance of the class is changed or the order of slots
in storage is changed, the function {\bf update-instance-structure} is
called whenever an instance of the class is updated, to complete the
transformation from the old representation of the instance to the new
representation.  Implementations may choose to invoke 
{\bf update-instance-structure} under other circumstances as well.
Programmers can define methods for {\bf update-instance-structure} to
specify actions to be taken when an instance is updated.  When
{\bf update-instance-structure} is called, the structure of the instance
has already been converted to conform to the new class definition,
and newly added slots are uninitialized.

Note that redefining a class may cause slots to be added or deleted.
When an instance is updated,  new slots are initialized and the
values of deleted slots are discarded.  Each local slot of the new
version of the class with no slot by the same name in the old version
of the class 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.  This is the same as the initialization
done by {\bf make-instance} except that no initialization methods are
invoked and no {\bf make-instance} initialization arguments are
present.  This initialization is performed by the default primary
method for {\bf update-instance-structure}.

\eject
If in the new version of the class there is a local slot of the same
name as any slot in the old version of the class, the value of that
slot is unchanged.  This is true regardless of whether the old slot
was a local slot or a shared slot.  This means that if the slot
has a value, the value returned by {\bf slot-value} after
class redefinition is {\bf eql} to the value returned by {\bf
slot-value} before class redefinition.  Similarly, if the
slot was uninitialized, it remains uninitialized.

If in the new
version of the class there is a shared slot of the same name as any
shared slot in the old version of the class, the value of that slot
is unchanged.  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 updated at the moment of class redefinition and 
are not affected by the updating of an instance nor by the
values of any local slots.

The \CLOS\ guarantees that {\bf defclass} can be used to change the
definition of an existing class that was previously defined by {\bf
defclass} as long as the {\bf :metaclass} option is not used in either
the old or the new definition.  Whether {\bf defclass} is allowed to
change the metaclass and whether redefining a class causes existing
instances to be updated is up to the implementor of the particular
metaclass.  ``The \CLOS\ Meta-Object Protocol'' will describe how to
control this.

\endSection%{Redefining Classes}