Thanks for taking an interest, Brent. Interesting that you're using atoms rather than vars - it means that method registration is no longer thread-local. I wonder if there could be a scenario where method registration was actually used to coordinate between threads? :-)
That could actually be useful if you were using plural dispatch as an event dispatching system, though whether it would be wise is another question... Cheers, Chris On 6 September 2012 20:27, Brent Millare <brent.mill...@gmail.com> wrote: > I've made my own take of your plural dispatch system. > > https://gist.github.com/3659663 > > I switched from using vars and a map for determining which pluralfn to > use, to atoms and metadata tied to the pluralfn. My method reduces the > amount of indirection and invocations. I originally tried to make a deftype > version to store the data, but then I'd have to reimplement all of the > microsyntax of of clojure.core/fn and expand out the args to all the > arities, not fun. > > Also I created defplural-body which doesn't specify the argument arity > which you can use to avoid sequencing/unsequencing arguments for > performance. I defined defplural in terms of defplural-body, which > maintains compatibility with your examples. > > My code has the advantage over some implementation details in multimethods > in that redefining the pluralfn does not cause you to forget all the > implementations since defplural-body checks for existing implementations. > This, however, will require the user to run clear-implementations! if one > does want to forget all the implementations. > > > On Wednesday, September 5, 2012 6:48:36 AM UTC-4, Chris Ford wrote: >> >> I was watching David Nolan's talk about predicate >> dispatch<http://blip.tv/clojure/david-nolen-predicate-dispatch-5953889>, >> and he articulated something that I've found frustrating about multimethods >> - the set of implementations is open, but the dispatch function is closed. >> That means that if your dispatch value can't be computed in the same way >> for all your data, you can't use multimethods. >> >> Predicate dispatch allows implementations to be registered with a test >> that decides whether or not they are applicable, so it can do things that >> multimethods cannot. For example, predicate dispatch would allow you to >> write an open function that categorises integers as "prime", "perfect" or >> some other category without baking them all into the dispatch function. >> >> In his talk, David speaks about the problem of overlap. 2 is both "prime" >> and "even", for example. That got me thinking whether overlap is a bug or a >> feature. >> >> I've hacked together a simple plural dispatch >> system<https://gist.github.com/3634871>, >> which allows the specification of a custom resolution function that can >> decide whether to use one or all of the registered implementations. You can >> use this system to implement both multimethods and predicate dispatch. >> >> What practical reason would you have for doing this? Random dispatch! >> Can't decide which implementation to use? Now you don't have to! >> >> (defplural random (fn [implementations args] (-> implementations rand-nth >> (apply args)))) >> (defimplementation random #(+ % 100)) >> (defimplementation random #(- % 100)) >> (random 1) >> >> It could also be useful for gathering a set of all possible results, >> quasi-AOP extension points, broadcasting events etc. >> >> Cheers, >> >> Chris >> > -- > 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 -- 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
