Updating Obsolete Instances

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

One of the open questions we should resolve next week is what the
protocol should be for updating obsolete instances (instances of
obsolete classes).  I present here a radically simpler proposal than the
ones we were most recently considering, though it bears strong
resemblance to some that were discussed earlier.

Proposal:

A class becomes obsolete when it is redefined (directly or indirectly),
the instance slots it specifies changes, AND it has one or more
instances.  For classes that are instances of standard-class, we support
a protocol to update instances whose structure becomes obsolete.

If a class becomes obsolete, then we say its instances are obsolete
instances. Let c-new be the class specified by the new class definition.
Let obsolete-slots be the names of those slots that are not included in
the new definition, added-slots be the names of the new slots added, and
common-slots be the rest.  

Effectively what happens is that all the obsolete instances become a
subclass of a newly defined class that has as direct-superclasses
(obsolete-class c-new).  Hence, all methods applicable to instances of
the new class are applicable to the old instances. 

However, the first time an attempt is made to access a slot-value of the
obsolete instance, the structure of the instance is updated to the
current structure before the slot-value completes.  The updating is done
(effectively) as follows:

1) Values of all slots in the old instance are saved
2) The structure of the instance is made to correspond to the structure
specified by the current class definition (and it is an instance of
class c-new)
3) Values of all common-slots are inserted in the new instance structure
in the same named slot
4) The generic function obsolete-instance-updated is called.  Its
arguments are the instance (now with the new structure) and a property
list containing the names and values of the obsolete-slots.  There is a
method on standard-object for obsolete-instance-updated

(defmethod obsolete-instance-updated
   ((updated-instance standard-object) obsolete-slot-values)
...)

This method initializes (from initform) any slot in the new structure
that is not already bound.  Slots without initforms are not touched.

Note that by specializing obsolete-instance-updated, one can do work
before or after, or instead of the initialization of unbound slots. 

To enable users to cause instances to be updated without having to add a
phony slot, or some other abomination, we provide a generic-function:

(make-class-obsolete class)

with a method for standard-class that has the appropriate effect.

DISADVANTAGES
1) This proposal specifies that updating will not happen until a slot is
accessed.  Perhaps this is too restrictive on implementations.

2) Methods applicable to the old class, but no longer current are not
usable.

3) This proposal does not support sequential updating of a chain of
obsolete structures. The only information it provides is the set of
obsolete-slots and values.  We could make it possible to determine which
version of the obsolete class was involved in the update by passing the
obsolete-class as a second argument to updating-obsolete-instance.  But
I don't think this is worth it. 
 

ADVANTAGES
1) It specifies exactly when the update will happen, and hence is
guaranteed to minimize the work done; that is, no instance is updated
until it needs to be.  It is possible to test if an instance is obsolete
by checing its type (seeing if its class is a subclass of
obsolete-class).

2) It ameliorates a problem we were discussing about how long what
methods must be kept around etc.  No old versions of methods are kept.

3) It is simple to explain.  Only one instance and class is involved in
updating-obsolete-instance, and the obsolete-slot information is passed
explicitly. The default behavior is what I claim is usually wanted.