Multimethods vs. cond?

[Bryce]

I'm wondering what the rationale is for using multimethods vs. cond,
and where it's best to use either? Multimethods seem to be very
seldom used, usually to dispatch on type, but I can see advantages to
using data to dynamically define only the methods you need, rather
than having all-encompassing cond statements. It also seems like
generally cleaner code. Is there a speed benefit to one or the other?

[Laurent PETIT]

2010/2/11 Bryce <fiat....@gmail.com>:

There is clearly a speed benefit of just using cond, and sometimes it
can be the reason for the choice.

multimethods help you implement the Open / Close principle : they are
open to users providing more specific implementations for more
specific dispatch values. And for this it is not necessary for the
user of the multimethod to change existing implementations for certain
dispatch values (the close part).

There's certainly much to say about the differences, but here's my contribution.

HTH,

--
Laurent

[David Nolen]

Multimethods also support reflection.

David

[Jeff Rose]

Yeah, in practice it seems like multimethods are pretty much just used
as a way to let users of a library extend the API to support
additional types. If you had a cond expression dispatching on the
type of an argument, for example, then the user would have to modify
the source code of your library to add support for their custom type.
With multi-methods the user can implement a method defined in the
library that dispatches on their own type, and the code can stay
within their own project.

I have a feeling multimethods could be useful for of plenty other
things, but so far that's all I've seen or done with them.

-Jeff

On Feb 11, 4:27 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> 2010/2/11 Bryce <fiat.mo...@gmail.com>:

[Raoul Duke]

hi,

the expression problem
(http://en.wikipedia.org/wiki/Expression_Problem) talks about some of
the relevant trade-offs.

sincerely.

[Daniel Werner]

You may also be interested in using pattern matching. It allows
dispatching based on structure or equality of your values, somewhat
similar to what you could do in Haskell or OCaml:

http://www.brool.com/index.php/pattern-matching-in-clojure

Being mostly a glorified cond, however, it shares the same lack of the
Open/Close principle, as Laurent put it. For the most trivial of
cases, when openness is not an issue, you may even get away with using
a map (as in some parts of clojure.contrib, I believe):

(def month-name {1 "January", 2 "February", 3 "March", ...})