1. It depends, if you reload the namespace for some reason, the value will
be reset to what is specified in the file, otherwise it's just once. By
using defonce you avoid it being reset.
2. Attemping what, reloading your code? I believe this is some scenario
people don't care too much about. Also atoms work well when accessed by
different threads, because its value is changed by an atomic
operation(swap!).
I hope my answer was somehow useful, happy hacking!
On Sun, May 22, 2016 at 5:35 PM, Colin Yates <colin.ya...@gmail.com> wrote:
> Others will have more idea, but my observation is that it is evaluated
> once, so a namespace which is required by multiple namespaces will only
> be evaluated once. Should you explicitly re-evaluate it then it will of
> course be evaluated again.
>
> You might be interested in reading Stuart Sierra's 'reloaded workflow'
> and using the resultant Component library which has some input on this.
>
> The other machinery you might want to look at is defonce, which does
> exactly what it says :-).
>
> To give you peace of mind you could experiment with:
>
> (ns a)
> (def m (atom 0))
> (swap! m inc)
>
> (ns b
> (:requires [a]))
>
> (ns c
> (:requires [a]))
>
> And then load 'a' and 'b'. My expectation is that a/m will be 1
>
> As I say, this is from observation rather than inspecting the underlying
> machinery.
>
> HTH.
>
> lvh writes:
>
> > Hi,
> >
> >
> > Suppose I have a namespace that has some ns-level side effect, e.g.
> `(def atom {})`.
> >
> > 1. When is that executed? How often? (I think, from observation, that
> the answer is “when it is first required”, and “exactly once”; but it’s
> important for the correctness of my program that this is the case.)
> > 2. Is there a mutex preventing multiple threads from attempting that at
> the same time? If so, is that an accident, or a language guarantee?
> >
> > I don’t know if it matters, but in this case the side effect will be a
> method call on a jnr-ffi binding, so internally it will go off and
> synchronously initialize a C library. It’s fine if it gets called multiple
> times, but only if it has been executed by exactly 1 thread first. (It sets
> some state to signify that it’s initialized; if you call it when it’s
> already initialized, it just exits. It is _not_ re-entrant.)
> >
> > If these guarantees don’t hold, is there a convenient/canonical way to
> execute that side-effect synchronously? I’d like to prevent users of my
> library to have to remember to call an init fn in their main- if I can.
> >
> >
> > thanks
> > lvh
>
> --
> 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/d/optout.
>
--
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/d/optout.
