I don't see how creating MultiFn directly is any less safe than using defmulti which also creates mutable object. And multimethods are never pure functions (may return different values for the same argument after defmethod call). I think the documentation should explicitly state mutability and non-pureness of multimethods.
By the way, what was the motivation to make multimethods mutable? On 17 май, 20:52, Sean Devlin <francoisdev...@gmail.com> wrote: > You could create a local instance of clojure.lang.MultiFn in a let > binding, and access it directly. You can see the definition of the > object here: > > http://github.com/richhickey/clojure/blob/master/src/jvm/clojure/lang... > > The very good reason you DO NOT DO THIS is that this object is > MUTABLE. > > I STRONGLY RECOMMEND that you use a dispatch fn that returns a > keyword, and use that to select a closure from a hash map for local > bindings. > > Sean > > On May 17, 10:41 am, Mikhail Kryshen <mikh...@kryshen.net> wrote: > > > > > > > On 17 май, 12:07, Laurent PETIT <laurent.pe...@gmail.com> wrote: > > > > Yes, > > > > as David wrote, > > > > What you're describing is not single-dispatch-based polymorphism (e.g. > > > like in java), it's double dispatch (because you want to dispatch to > > > the implementation of the protocol function based on both the type and > > > another parameter which may be totally dynamic, or materialized -when > > > serialized- by some key in the configuration - spring bean name, > > > etc.). > > > That makes sense. It looks like I was trying to avoid explicit > > double-dispatch by manipulating the protocol at runtime. Is it abuse > > of dynamic features of Clojure? > > > > Protocols are based on a single dispatch mechanism, as classical > > > "class based" languages (e.g. Java) are. > > > > When you write "kind of expandability almost free with well-designed > > > OO systems", I guess this design implies some kind of implementation > > > of the Strategy pattern, or more probably Delegation pattern. > > > What I was actually talking about is the possibility to avoid global > > state and being able to extend existing implementation to multiple > > instances without much refactoring. > > > Protocols and multimethods both have global state. From what I saw in > > Clojure source protocols are manipulated by changing root binding of > > associated var, and multimethods are actually mutable functions > > changed by defmethod (I see inconsistency here). > > > There is no standard way to create multimethod or protocol without > > binding it to global var. Why is it possible to create non-global > > function but not multimethod? > > > -- > > Mikhail > > > -- > > 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 > > athttp://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 > athttp://groups.google.com/group/clojure?hl=en -- Mikhail -- 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
