On Saturday, January 5, 2013 3:12:43 PM UTC-5, Peter Taoussanis wrote: > > >> I will update and give the code a try. Thanks for the fast turnaround! >> > > No problem. > > >> As far as your first and last questions, they both sort of came from the >> same scenario I was pondering. I was thinking about an application made >> with many small dependencies and maybe several of them all were using tower >> to handle translations and such. But they don't about each other and, >> therefor, expect to work the same regardless of whether or not there are >> other libraries that also use tower. Each library might want a different >> default locale, or different mode (:dev/other), etc. I was just thinking >> about what happens in that case since there is but one "config" state in >> the tower namespace. Again, this isn't an issue for me I was just >> pondering the scenario. >> > > Hmm, let me think about this a little more. There's a number of options, > the simplest of which is probably just to offer a dynamic binding for the > config atom. That way each library can bind over the atom and get its own > config. > > Regarding the separate dictionary thing, I was still talking about the >> centralized dictionary where the arbitrary keys allow easy separation of >> the dictionary parts. I was heading down the path where multiple sections >> of the dictionary were created by different libraries merging in different >> dictionaries from different resources in their own code bases (using >> something like load-dictionary-from-map-resource!). If one of those >> resources changes (in dev mode) then I think we might want to just re-merge >> that resource's contents into the dictionary, replacing just the parts >> merged from that resource while leaving the rest of the dictionary >> unscathed. I was wondering if a "merging" version of >> load-dictionary-from-map-resource might be useful for that situation. >> > > I'm sort of half-following what you mean here... I think between the 1.2.0 > update and the dynamically-bindable config, you'll probably have what you > need. Could I ask you to create an issue for this on the GitHub page, then > I can come back to you when I've got something implemented? >
Sure, I'll create an issue. I was thinking about the dynamic scoping of the config (and anything else driven by that as needed) right after I clicked submit... -- 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
