CLOS vs FLAVORS questions

[gooch@sw-sw.dialnet.symbolics.com (William D. Gooch)]

    Date: Wed, 29 Jan 1992 19:37 CST
    From: jbarnett@charming.nrtc.northrop.com

    In the near future, I intend to start hacking a medium large system and
    am considering using CLOS on Symbolics platforms.  I'm seeking comments
    and advice to help me decide if this is wise.  I have read the SIGPLAN
    special issue on CLOS, Keene's book, and the documentation provided by
    Symbolics.  I'm trying to understand if CLOS compares favorably to the
    current flavors capability.  

Overall I think the answer is "Yes."  I can't think of any very good
reason not to use CLOS for new development work.

	Some particular questions are:

    Are CLOS programmers really able to use the dispatch-on-multiple-args
    capability effectively?

Yes, and there are situations when it is truly a valuable capability.
The example I have encountered is in copying/merging structures between
a Statice DB and a cached representation used for high-performance
interaction.  Multi-dispatch is useful here because the exact nature of
a copy depends on the types of both the source and target objects.

	Does EQL dispatching get used in nontrivial
    ways (same argument specialized sometimes by class, sometimes by a
    symbol, etc.)?

    I found the flavors MIXTURE option very useful.  In your experience,
    does the dispatch-on-multiple-args capability compensate for the loss
    of MIXTURE?  The alternative seems to be dynamic evaluation of DEFCLASS.
    What are other techniques to get some of MIXTUREs capabilities?

I have also found :mixtures to be useful at times.  I don't think
multi-dispatch really offers an alternative to what :mixture can do, but
the ability to change the class of an instance dynamically (which you
can also do in flavors) generally does.  Modifying and reevaluating
class definitions is not necessary.  See CLOS:Change-Class.  

    On the surface of it, the repetitive use of WITH-SLOTS and/or
    WITH-ACCESSORS appears to be insidious and tedious.

Agreed, but this is a basically a minor annoyance, and it does improve
code clarity somewhat in my opinion. 

	There seems to be
    a lot of extra work for the common case where a method only specializes
    on one arg.  Has your experience shown this to be a groundless fear on
    my part?

Not "a lot" of extra work, but some.  It's a tradeoff.

    In my application, I invision using the CLOS first-class capability to
    change an instance's type so that different methods become applicable as
    the object moves through its life-cycle.  (I know that flavors does not
    have a first-class set of tools to do this.)  Are implementations of
    this capability efficient enough to really be used?

The Symbolics one is, in general.

    My reading of part of the CLOS spec was ambiguous.  The case I have in
    mind concerns reevaluating a DEFCLASS where I have implemented methods
    to assist in the "correction".  If I only do one redefinition, I don't
    have any questions.  If I do TWO (or more) redefinitions and I define
    helper methods for each, do the CLOS semantics guarantee that all sets
    of helper methods get executed and in the proper order?

I'm not sure I understand this question.

    Another puzzle for me was the use of the DEFINE-METHOD-COMBINATION option
    :IDENTITY-WITH-ONE-ARGUMENT.  Consider the operator "+" and note that
    "(+ (F))" is not the same as "(F)" if "F" returns multiple values.
    What are the actual, intended semantics of this?

Sorry, I can't help you here.

    I would appreciate any comments on these questions and any other reports
    of impressions and experiences with CLOS.  In particular, I'm interested
    in same to help compare generic function systems (CLOS) and message
    sending systems (FLAVORS).

Of course, Symbolics flavors has been generic-function based for some
time now, and SEND is only necessary when using methods that haven't
been changed to the new form yet (many things in the window system, for
example).