A middle ground between dynamic vars and passing state through functions that themselves don't need it, but which is needed by functions they call, is to build on top of defprotocol and defrecord, to refactor so that the functions that need "configuration" state in their operations are defined by protocols, and the state they need is captured in a record, which can then be prepared at initialization time with the necessary information.
In this solution, there is still "noise" in the sense that now protocol "functions" have to take their record configuration as a first parameter, but the semantic noise in having unused configuration data passing through that first parameter should be relieved. There's a lot more to say here, but the upshot/goal of the refactoring should be that explicit dependencies between the function call tree- organized into protocols- and initialization/configuration state- organized into records- should be nicely revealed. There are reasons that they might not, and then that's a time to look at other state/configuration management approaches like atoms/refs and dynamic vars. Someone else mentioned Stuart Sierra's Component library: https://github.com/stuartsierra/component Stuart seems to have gone furthest in encapsulating this pattern, so his examples are good to think about, even if you don't adopt the library. HTH. On Mon, Jan 13, 2014 at 8:50 AM, James Trunk <james.tr...@gmail.com> wrote: > I've been investigating how to handle configuration in a Clojure > application/library, and have discovered two main candidates: dynamics vars > and argument passing. > > The downsides to dynamic vars seem to be: hiddenness, thread safety, and > more complex tests (binding before each test). > > The downside to argument passing is noise in the code (especially when > you're just passing the config through). Longer and more descriptive names > for the config (i.e. not "ctx" or "cfg") make this noise even more painful. > > Are there any alternatives that I've missed? What is the current best > practice for handling configuration? > > Cheers, > James > > -- > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
