On Mar 27, 5:56 am, Konrad Hinsen <konrad.hin...@laposte.net> wrote: > On Mar 27, 2009, at 9:25, Mark Engelberg wrote: > > Considering how complex the situation can get with single dispatch, I > > imagine it gets even more complex in multiple dispatch situations. In > > the multimethods example at clojure.org/multimethods, an example is > > given of disambiguating between [::shape ::rect] and [::rect ::shape]. > > But again, if you're writing the bar method from outside of the > > library which defines ::shape and ::rect, you might not even know > > which is more specific. It might be easier to choose a strategy, such > > as more specific on the leftmost taking precedence, than to know the > > details of how the various types in the library interact. > > I am not so sure about this. I wonder if there is a real-life use > case where a client library would need to solve dispatching issues on > types in another library about which it doesn't know anything. No, because such a library won't get used. If I offered a customer a library with the caveat that his people might run into unexpected dispatch conflicts that could be solved simply by reading the library sources, he'd say, "thanks, I'll pass." > If > there isn't, the problem is not relevant, and if there is, I'd like > to see a demonstration that something like left-to-right precedence > is indeed a reasonable default. I can tell you about large software projects in which left-to-right precedence worked well. "Demonstrate"? That's a lot of code to recapitulate! There is nothing magical about left-to-right precedence, except that *you know in advance what it is*. You can reason about it, because you know what it is. You can predict what kinds of uses will be a problem, and therefore can avoid those problems. For purposes of writing reusable and extensible subsystems, *any* defined order is better than no defined order. > On the other hand, I would definitely like to be able to implement > left-to-right precedence myself on top of Clojure's multimethods, and > it seems that at the moment this is not possible. There it is: it's fine if Clojure doesn't define a default and universal traversal order for MultiFn dispatch, as long as I can define such an order when I need it. prefer-method isn't quite enough, because it only works on dispatch values that are already defined. In order to make a safely-extensible library, I need to be able to prescribe a traversal order over dispatch values that haven't yet been created. I have a separate issue with prefer-method, in that it defines traversal order implicitly, in a way that is hard to digest. That is, you can't look in one place to find out what the traversal is; you instead have to search out all the prefer-method calls and piece the order together from examining each of them. That's tangential to the present discussion, though. If none of these considerations moves Rich much, that's okay. He gave us the tools we need to write our own solutions. --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
