Recent questions about CLOS

[gooch@TIJERAS.SW-SW.Dialnet.Symbolics.COM (William D. Gooch)]

    Date: Tue, 18 Sep 1990 18:58-0400
    From: Moon@STONY-BROOK.SCRC.Symbolics.COM (David A. Moon)

    ....
    The committee that defined CLOS wasn't interested in putting in
    optimizations like ordered-instance-variables or compile-flavor-methods.
    I don't think we want to put a lot of nonstandard extensions into Genera
    CLOS, after all, there's no real reason to convert from Flavors to CLOS
    if you aren't going to port your code.  And if you are going to port
    your code, nonstandard extensions don't do you any good.  Therefore I
    would think the answer is no; this is not a commitment on the part of
    Symbolics, of course.

There is good reason to consider converting to CLOS if you think you
1might0 need to port your code sometime in the future (there are probably
other good reasons, such as a need for method dispatching based on the
types of multiple arguments).  This is quite significantly different
from waiting until you know for sure that you need to port your code,
then doing the conversion in a big rush when it wants to have been done
yesterday.  I can understand that the committee didn't want to concern
itself with issues of optimization, but I expect that the vendors should
and would do so.  I am very happy to hear that CLOS now generally has
good performance, and I thank you for alerting me to that fact, because
it means that I may not need to wait until stuff really hits the fan
before converting to the standard approach.

Ordered-instance-variables doesn't appear to be a significant issue in
most cases, but in my experience, interactive programs often can benefit
from the appropriate use of compile-flavor-methods (or its equivalent in
CLOS).  In fact, I would much prefer to have combined method compilation
happen automatically prior to runtime for instantiable classes without
the need to explicitly ask for it (of course one has to somehow be able
to declare classes as being instantiable, which in itself would seem to
be a worthwhile addition to the CLOS standard, unless it's already there
and I'm just missing it).  This would then not need to be a non-standard
extension, since the optimization itself would be transparent.  Barring
this, I would settle for a CLOS equivalent of compile-flavor-methods.