On 16/05/13 15:07, Phillip Lord wrote:
Yep, that's the problem. The library in question
(https://github.com/phillord/tawny-owl) is meant to be usable by people
who don't want to know that they are writing clojure.
Funny that you're writing an ontology lib - my research is increasingly driving me towards using ontologies and therefore I may actually be your first user! (assuming that the lib is still in construction and has no users yet). :-)

It's useful, but scary. It mixes with laziness badly, but then, so do
exceptions.

It's nice, though for use in test fixtures....

(defn ontology-reasoner-fixture [tests]
   (binding [r/*reasoner-progress-monitor*
             r/reasoner-progress-monitor-silent]
     (tests)))

for instance. This prevents the code from either poping up a GUI or
generating lots of spam output, which is not good in a test.
I'd write it like so:

(defn ontology-reasoner-fixture
[tests & {:keys [monitor]
              :or {monitor r/reasoner-progress-monitor-silent}}]
  (tests monitor))) ;;tests fn needs to accept an arg

And having established a clear use case, which appears well motivated
and sensible, Clojure prevents me from providing the same convenience
knobs for my own library; at least in the same way.

Okay, so I can use atoms. My question, why does clojure.core not?

many of these settable vars point to something mutable in the first place (e.g. *in* & *out*). It wouldn't make sense to wrap them in atoms - it would be a waste of semantics. Imagine wrapping an arraylist with an atom...what is the point?

And which is the right default to pick? This is the problem. On my big
screen, the GUI is okay. On my netbook, it's a pain. On travis, running
headless, I want /dev/null.

I can't express any opinions on that I'm afraid...I thought that your 'default' behaviour was clear to you..something like "always use silent monitor unless the user says otherwise". The way you're describing it now it sounds like the ability to specify profiles in leiningen is what you need...since you can't avoid this particular type of 'deployment-specific' state, a config-map wrapped in an atom would suffice I think.

HTH,

Jim



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


Reply via email to