Hi,
I think it depends on what your options are actually doing, what has
to be so configurable. Maybe you can extract this configurability with
a more functional approach? For example instead of specifying a
algorithm to use in the options map, make it a parameter of the
backend function and let the frontend plugin a suitable fn depending
on the user choice. Or store away such information in your data
structure and use multimethods to dispatch on this information. In how
far such alternatives are viable depends really on the nature of your
options.
Another solution is to "fix" the bindings for the lazy-seqs:
(defn uses-foo-and-bar-options
[stuff]
(let [{:keys [foo bar]} *options*]
(map #(do-stuff-with foo bar %) stuff)))
bound-fn will also remedy this problem:
(defn uses-the-options
[stuff]
(map (bound-fn [x] (do-stuff-with (:foo *options*) x)) stuff))
However this will most likely not be the fastest approach.
In a totally representative query ;), I thought about my code. And I
almost never find the need for binding. If I use it, it is really in a
local context. Eg. rebinding *out* for a couple of local prints.
Maybe you can post some example, what you want to do? Then it is
easier to come up with some concrete ideas.
Sincerely
Meikel
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
