Re: Gabriel's Comments

[Jim Kempf <kempf%hplabsc@hplabs.HP.COM>]

Some further comments on class changing and staticizing.


>    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
>    dispatch.
>


>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 think the revelent word here is "environment." How much of the
change-class functionality should be part of the language definition
and how much a part of the environment?

> 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). 

Not necessarily. With multimethods, the developer may have some
methods which discriminate on a staticized class through any number or
order of arguments. Building a staticized class may not mean
that you don't want to subclass; in fact, staticized classes
might be build into class libraries for incorporation into
different applications, with developers specializing them 
for particular purposes.

> 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.

Perhaps using the metaobject protocol to define a STATIC-CLASS
metaclass is one solution. This would mean STANDARD-CLASS leans
heavily towards a prototypying vehicle, however. How STANDARD-CLASS fits
into the Common Lisp DECLARE mechanism (if at all) still needs
to be resolved.

>    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.
>

That is one way to look at it. Considering the fact that CLtL makes
practically no guarantees about what is EQ, it may leave a big
hole open to implementors. As an example, consider the case with
vectors which are fasled. I've worked with two CL implementations
which take completely opposite approaches. In one, a vector which
is inserted into two places into code that is compiled will later
be EQ when the code is loaded. In the other, this isn't the case.
Integers don't necessarily have to be EQ in CL (and, in fact,
aren't in one implementation). I don't want to get into a long,
philisophical discussion about EQness, but just want to point
out that unless we are very clear about this and about how 
CLOS fits in with Common Lisp, we may end up with a certain
amount of implementation chaos.

		Jim Kempf	kempf@hplabs.hp.com