Konrad Hinsen <konrad.hin...@laposte.net> writes: > But for many of Clojure's plain functions, it is not clear what their > dispatch function should be if they were to be converted to > multimethods.
Indeed. It can be a non-trivial design exercise. But your clojure.contrib.generic code shows that one can make headway on the problem, especially for operators on collections which I would expect to have polymorphic behavior. > As for the performance issue, Clojure is different from most other > languages in that its built-in functions have no very special status: > they are just the values of some vars in the namespace clojure.core. > It is rather straightforward to define equivalent multimethods in > some other namespace and use those instead. Sure. It's easy to write one's own version of get et.al. What's hard to do is to get packages that you didn't write to use that version of get. You need everyone to use c.c.generic.collection or all the different libraries will have trouble interacting with each other. There is this same namespace problem in Common Lisp, if you're familiar with that package system. While it's possible to use the same names as are in the CL "core", almost no one does. Cheers, Chris Dean --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
