> 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?

-- 
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

Reply via email to