[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gabriel's Comments

    With regard to class redefinition, lazy update would certainly
    get rid of having to keep pointers around in classes, but would
    introduce an extra operation during method dispatch, slot access,
    or whatever operation was chosen to do the update. Since method
    dispatch is 100% overhead as far as the applications programmer is
    concerned, the question is whether the added flexibility of having
    the class update automatically is worth the extra time spent
    checking during method dispatch. Similarly with slot access.

    Note that inserting update into dispatch could also interfere
    with staticizing a class. Suppose you have finished developing a
    class and now want to staticize it. If method dispatches must check
    whether instances need to be changed, staticization needs not only
    to affect classes but also methods dispatching on the classes,
    since the check for changes in the class must be removed from the

The issue you bring up here can be characterized in terms of a tradeoff
between a good development environment and one fully optimized for
speed.  I assume that when you talk of "staticizing a class" you really
mean "staticizing a set of classes and generic functions which apply
only to those classes".  And that the former means that you expect not
to build any subclasses of the staticized classes (or at least have them
staticized immediately).  The purpose of the meta-object protocol in
part is to allow you to change the implementation of a set of classes by
defining the implementation structure, and optimizations of slot access
and method lookup.  For classes of such metaclasses, neither
CHANGE-CLASS nor instance updating (CLASS REDEFINITION) need work.
These are only guaranteed to work for STANDARD-CLASS.

    In addition, the question of whether changing a class
    definition and having instances still be EQ is consistent with
    Common Lisp's EQ semantics needs to be resolved.
It is the same semantics as EQ when a list structure has been RPLAC'd.
EQ implies a continuity of history and coreference.