What I usually do when I want to avoid passing these implicit parameters is just use thread-local bindings with ^:dynamic vars. From the point to rebind them using (bindings), every function called from within the binding block sees the same value; you can combine them with atoms/agents/refs for even greater flexibility, and still avoid polluting your namespace. One way to think about that, in my opinion, is that by having your namespace top-level vars hold references to state, you are effectively turning your namespace into a singleton object, which is typically not a good idea even in Java. Starting with Clojure 1.3.0, I believe pmap and some other core functions that work with threads even take care of propagating your thread-local bindings to child threads for you.
Anyway, I can see that there really isn't a consensus on this. On Wednesday, September 12, 2012 5:23:32 PM UTC+2, Gaz wrote: > > I find myself having to make similar choices quite often in my own > Clojure code - do I create perhaps a map of things that represent some > kind of 'state' and pass that around to each function that needs it, > or do I do what has been done above and create some vars in a ns where > most (all?) the functions that use this data live. > > I think either can be the right choice in different circumstances. For > example, I always store configuration data in a var that has a few > functions using it rather than passing a config map to every function > in the application that needs access to it. I just use those functions > throughout the codebase instead. > > I'm not at all familiar with noir so cannot answer your question > regarding that specifically, but I would say using your own judgement > is a "Clojure best practice" :) > > On Wed, Sep 12, 2012 at 9:30 AM, the80srobot > <ad...@ingenious.cz<javascript:>> > wrote: > > Is this a Clojure best practice? > -- 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
