On Fri, Mar 27, 2009 at 4:58 PM, mikel <mev...@mac.com> wrote:
>
>
>
> 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.
>
There is prefers:
(prefers print-method)
-> {clojure.lang.ISeq #{clojure.lang.IPersistentCollection
java.util.Collection}, clojure.lang.IPersistentList
#{clojure.lang.ISeq}}
> If none of these considerations moves Rich much, that's okay. He gave
> us the tools we need to write our own solutions.
Hang tight - I hear your concerns and am thinking about them.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
