[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gabriel's Comments
- To: kempf%hplabsc@hplabs.HP.COM
- Subject: Re: Gabriel's Comments
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 11 Mar 87 07:56 PST
- Cc: firstname.lastname@example.org
- In-reply-to: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>'s message of Tue, 10 Mar 87 09:31:52 pst
- Sender: Bobrow.pa@Xerox.COM
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.