Could possibly clojure multimethods be enhanced to support more general use
cases (enabling to e.g. define generic functions on top of it), while still
be fast for the current behavior ?
It seems to me that being able to redefine the function that matches the
computed dispatch-value of the call to the multifn to the declared
dispatch-values, plus the possibility to customize the algorithm used for
disambuiating candidate methods could be enough ? (maybe not for the
next-method .. stuff, but a basis for finding the next-method could be based
on the disambiguaiting algorithm if it is implemented like a comparator ?)
Then defmulti could accept two additional arguments (maybe forcing that the
default value be also present in this case, for backward compatibility) :
(defn clos-like-dispatcher [computed checked]
(every? identity (map isa? computed checked)))
(defn clos-like-disambiguier [val-1 val-2]
(if (every? identity (map isa? val-1 val-2))
val-1
val2))
(defmulti add (partial map type) :default clos-like-dispatcher
clos-like-disambiguier)
... Or something more performant by being able to override the global
disambiguing function given the list of all candidate values at once ...
Could something this be added to multi-methods, with as an optimized default
the current behavior ?
It seems that it then could be the basis for clos-like generic functions,
and a lot more cases (because it then becomes more general) than it is
currently (it seems very harcoded currently).
--
Laurent
2009/3/25 mikel <mev...@mac.com>
>
>
>
> On Mar 24, 10:51 pm, mikel <mev...@mac.com> wrote:
> > On Mar 24, 5:37 pm, Meikel Brandmeyer <m...@kotka.de> wrote:
>
> [...snip...]
>
> I wanted to call out a point that I made before, but that is maybe
> buried in a little too much verbiage. The point is that there is maybe
> a way for me to implement an automated and predictable answer to the
> question you raised:
>
> =======================
>
> Suppose the following situation:
>
> (define-method foo [x some.inter.Face] ...)
> (define-method foo [x some.other.Interface] ...)
>
> Now suppose you call this function foo with something like
> (proxy [some.inter.Face some.other.Interface] [] ...). Which
> magic decides which method to use?
>
> ========================
>
> The answer I propose is that dispatch chooses some.inter.Face first,
> because it appears leftmost in the sequence of interfaces you provided
> to proxy.
>
> That's not currently implemented because I'm not sure yet if the order
> of interfaces reported by a proxy object is reliably stable, and
> whether it reliably reflects their order in the original proxy
> expression.
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
