[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CLOS vs FLAVORS questions
Date: Wed, 29 Jan 1992 19:37 CST
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
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
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
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