Re: Gabriel's Comments

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 10 Mar 87 09:31:52 pst
    From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
    ....
    CLASS REDEFINITION

    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.

Method dispatch isn't slowed down, since you simply make there be no
methods applicable to obsolete instances, other than a default method
that updates the instance and tries again.  This works well in New
Flavors and I believe has been used in other object systems as well.

Slot access by calling an accessor generic function isn't slowed down
because that goes through method dispatch.

Slot access by calling the SLOT-VALUE function is slowed down, but
probably infinitesimally compared to the cost of looking up the name
of the slot in a table to get the position of the slot.

Slot access by special implementation-dependent compiler-optimized
technique is defined to prefer speed over the ability to change the
class at any instant; see the mention of semantic difficulties on page
2-9.  (There used to be a more explicit discussion here.  Where did it
go?)

It's probably safe to say that there are a number of things in this
proposal that seem at first glance to be inefficient, but actually
are amenable to clever implementation techniques.  Someone should
publish a paper outlining those techniques so all implementors
concerned with maximizing efficiency can use them.

    Note that inserting update into dispatch could also interfere
    with staticizing a class. 

I suspect that everyone means something slightly different by the
term "staticizing a class."  But whatever it means, surely it could
be defined to rule out the ability to use change-class on instances
of that class.

    Problems with WITH-SLOTS and with inadvertent trashing of important
    classes ala` the example with TEXT-BUFFER remain to be solved.

I assume that was the following, from your 23 February message:

    3) What happens to methods written on the old class? Do they
    stop working? 

Only if they depend on an aspect of the class that is no longer true.
Note that there isn't really "an old class" and "a new class"; there
is only one class.  Redefining a class updates the existing object
rather than creating a new object.

		  What if the methods contain a WITH-SLOTS and
    some of the slots accessed within the scope of the WITH-SLOTS
    disappear? 

The semantics of WITH-SLOTS is defined in terms of calling accessor
generic functions (and hence calling accessor methods) and SLOT-VALUE.
So either you get a no-applicable-method error from the accessor
generic function or SLOT-VALUE signals a no-such-slot error.

	       Automatic instance updating would limit the amount
    of optimization that could be done during a WITH-SLOTS expansion,
    since changing the number of slots could invalidate any attempts
    to directly access the slot values (like, for example, trying
    to get rid of the double indirect referencing mentioned above).

Perhaps my earlier answer to this got lost.  Double indirection is
not the only possible implementation technique.  Also the possibilities
for optimization are enhanced by the "semantic difficulties" note
mentioned above, which essentially says you can't change the class
while a method is executing (it isn't quite that strong).  Also in
a multiple inheritance system, doing the optimization I think you are
thinking of (compiling positions of slots directly into compiled methods)
requires some kind of restriction, possibly "staticizing the class",
and in this case either changing the class would be forbidden or
(as in New Flavors with the :ordered-instance-variables option) changing
the class would be permitted but the system would enforce a restriction
that those slots could not move.

    What about accessor functions? Are they undefined? Redefined
    to give an error?
    
See the first paragraph on p. 1-11.  It's a pity we don't have a more
tutorial-style document, in which answers to questions like this would
be easier to find.  The accessor methods go away, the accessor generic
functions remain defined of course, since other classes might also
have methods for them.  I'm not sure if we said anywhere what happens
when you call a generic function and there is no applicable method;
I think it ought to signal an error.

    4) Automatic instance updating, in and of itself, could have
    potentially serious side effects in every day use.

I don't see how the scenario you gave (redefining a class that the
programming environment depends on, and putting a bug into it) is any
different from redefining a function that the programming environment
depends on, and putting a bug into it.  An extra powerful programming
environment might have ways to defend itself against both of these
problems, but I don't think any special language features are called for.

    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.

True.  I've been collecting a list of issues like this, and this is on it.