Re: Gabriel's Comments

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

Sorry it's taken so long to get around to this. Starting from
the bottom up, here's some replies to Dick's comments:

METHOD COMBINATION

>``7) General comment on method combination. It is certainly clearer now
>than in the original documents, but I wish the preciseness with
>which the inheritence algorithm was specified could also be true
>of method combination. ''
>
>Moon (and Sonya) spent some effort cleaning this section up. Nevertheless,
>I judged it needed more rewriting, but I could not muster the enthusiasm
>or time to do it myself. I had a hard enough time making sense of the
>originally confusing uses of the terms ``primary method,'' ``auxiliary
>method,'' and ``unqualified method.''
>

I think my problems with the section had nothing to do with its casting
in English, but rather with a general dissatisfaction with using
English to describe something so complicated. As there doesn't seem
to be much choice of a more precise language at the moment, I think
the current version looks OK.

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.

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.

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

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.


INHERITANCE OF SLOT DESCRIPTORS

Due to problems with our mail delivery, my note got delivered
after Moon's simpilified slot descriptors note, although it
was mailed before. So I hadn't had a chance to look at it.
It looks to have simplified a good portion of the explanation,
but it would be useful to see it in context.

I think I understand the logic behind (AND ...) type specifiers
for inherited slots with the :TYPE option now, after some more
study. I think the desired specialization is being achieved with
this.