Clojurians Log v2

@schaueho: states can really be anything (i.e. any value), which means they can also be functions, as in send-sms example. your question is a bit orthogonal to mount / component. if you need to swap mongodb state with a test-mongodb, your test value should have the capabilities you need for your tests. you can get there with protocols (again nothing mount/component specific), with redefs, or simply with an embedded mongo db value (i.e. https://github.com/fakemongo/fongo / https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo)

@tolitius: Do you mean <http://clojure.java.io/resource|clojure.java.io/resource>? Otherwise I am not sure I understand the question.

@arnout: I mean an external resource: db, socket, broker, etc..

Can be anything really, but a simple configuration example would be:

(defstate config
  :start    (edn/read-string (slurp (io/resource path)))
  :bindings [path "/config.edn"])

Instead of creating a substitution that - for example - reads from another path, this way one could simply influence the path, without "repeating" the rest.

Most of the configuration of other resources would use such a config state of course.

It is suitable for passing command line arguments as well.

this feels more like something that should be driven by configuration.. defaults, different envs, etc.. as to command line args, I am not sure, since I don't have a solid (non (mount/args)) solution for that yet. But I also would expect command line args to just point to a config file that would host all these defaults.

but don't let this by no means stop you, this is just my view :simple_smile:

Sure, still I value your opinion in this. I think the number of use cases for it are slim, indeed. I do think it is a nice solution for command line arguments. From my updated issue: > [I think it is a] nice solution: no need for thread-local dynamic vars (which will break in parallel mode) or other fragile solutions. Bindings in that sense offer an easy, cleanly scoped and semantically clear way of passing values to states, ensuring the same values on stop as when a state was started I am just not sure if such a small number of use cases warrant including it. I have not used (nor needed) the feature in any of my defstates yet, except for a config path and CLI args.

yea, the API is a lot harder to change once added :simple_smile:

Exactly :simple_smile: pondering...