Re: Redefining Classes

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

        If the redefinition of a class causes the structure of
        its instances to be different...

    I think we're going to have to define this more precisely.  I
    see two options:

    (1) Adding or removing an instance slot definitely changes the
    structure, and some other operations may also change the structure,
    depending on the implementation.

    (2) The structure changes if and only if the value of
    (class-all-instance-slot-names class) is not EQUAL to its previous
    value. I made up the function name class-all-instance-slot-names,
    but you get the idea.  Note how class-all-slot-names won't work.

    The big difference between option 1 and option 2 is that with
    option 2, a given sequence of defclass forms will produce exactly
    the same sequence of calls to make-instances-obsolete in all
    implementations.

    I'm inclined to option 2, because it is more precise, but I'm
    worried that this might rule out some implementation possibility. 
    Also, for this to be meaningful and portable, we have to define the
    exact order of slots produced by slot inheritance, which is not
    something we've had to specify before now.

I agree with you on the choice of how one specifies this.  In the
metaobject protocol, we currently have a generic function

all-slot-names class &optional allocation 

which returns a list of slot names.

The allocation argument can be an allocation symbol (e.g. :instance,
:class), or nil meaning names for slots regardless of allocation.  For
allocation = :instance, the list returned by the implementation should
be one that is ordered by the implementation.  Thee is no method to
specify the order of instance slots in the instance.  An implementation
is free to decide on the layout (e.g. so that reversing two slot names
in a defclass form does not necessarily obsolete the instances).  By
documenting all-slot-names, we can avoid the specification of the
ordering rules, and still provide a specification of what we mean.

    I have two problems with [update-obsolete-instance].
    The easy problem is that I
    don't like the name update-obsolete-instance, because the instance
    doesn't really seem obsolete to me.  One idea is to take an analogy
    to class-changed and call it class-redefined.  In Flavors we call
    it transform-instance, but it doesn't have quite the same
    semantics.  It's likely that someone can think of a better name
    than any of these.
We could call it update-from-obsolete-instance, or
conform-instance-to-class.  Since it takes ans instance as an argument,
I don't like names like class-redefined -- which seems to focus on the
class.

    Much more important, I can't implement the specification that
    the slots are initially uninitialized and then they are filled in
    from values saved in a property list.  There are two problems, one
    obvious and one subtle.  The obvious problem involves slots that
    were unbound originally; since there is no Lisp value that means
    "unbound", there is nothing that can be put into the property list
    for these slots.  But if we don't put any entry in the property
    list, then the desired feature that the method can tell which slots
    were added or removed is lost; these slots look like they were
    added, even though they weren't.
  
We could designate such a value (make it be the value of a globally
accessible variable).  Then putting such a value in  a slot would be
equivalent to making it unbound.  I can hear the ARGHHH from here, but
it does make accessible something that we are having to make
programmable (e.g. SLOT-MAKUNBOUND ...).  Aside from matters of taste
(and I could be convinced on this fairly easily), why is it you could
not implement this -- is there a particular tradeoff that you are not
being explicit about?

    Also, the default method you
    mention below will put the :initform value into these previously
    unbound slots, which seems wrong.  "Unbound" should not be
    confounded with "nonexistent."
I feel that making unbound slots be initialized is a feature, not a bug.
One good reason to make a class obsolete may be to cause formerly
unbound slots to be initialized.  That is, one could redefine a class,
adding an initform option, and be sure that any instances that had that
slot unbound would now have it bound to the specified value.

    The subtle problem involves some language extensions that we
    have, allowing slots to have contents that cannot be expressed as
    Lisp values in a property list.  For instance, there is a mechanism
    similar to Prolog logic-variables which allows two slots to be
    linked together. This linkage has to be preserved in the face of
    class redefinition.
Can such linked values only be used inside of objects, and not within
lists?  I though inivisible pointers can be used anywhere.  I don't
understand what the assumptions underlying this extension are.

    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.

Without the reasons given above, I still like this proposal as well as
the one I wrote up.  It supports the proposed model at a better level. 
    I suggest conveying the desired information directly, rather
    than trying to be clever: Give update-obsolete-instance four
    arguments:
      the instance
      a list of the names of all added slots
      a list of the names of all deleted slots
      a property list giving the values of all deleted, bound slots

I actually think this is fine.  But I would also say that the underlying
implemention also initializes existing slots that were unbound, using
the initforms in the class, if any.
   
    I would say the default method initializes only the
    newly added slots.

Fine I will write it up this way.

        Because update-obsolete-instance is user code, its
        operation can be seen by the user; but the model that CLOS
        supports is that as far as the user can tell, all the existing
        instances of a class are updated as soon as the class
        redefinition happens.  This implies that the user must define a
        method for update-obsolete-instance before redefining a class.
        Implementations are free to delay the conversion of existing
        instances (for example, to method call or slot access time),
        but users should never be able to see the untransformed
        instance.

    We're going to have to specify this a little more precisely, I
    suspect. We should specify when is the latest time that an
    implementation can call update-obsolete-instance, and then say that
    it is permitted to call it any time earlier (after the class has
    been redefined).  I now believe that the latest time can simply be
    the time any of the four slot access and modification functions (or
    internal equivalent) is called, in spite of all the flaming against
    this we engaged in while discussing Danny's proposal at the meeting
    last week.

Agreed.