On Dec 20, 12:44 pm, chris <cnuern...@gmail.com> wrote: > 1. Is using defs the best way to go about this? They are global > variables; they model static state of the system, essentially.
Yes, global variables are probably best as Vars (which is what def creates). > 2. How do defs handle updating when I reload a file in the repl and > then something in some other thread triggers a render? Re-evaluating a def changes the "root binding" of a Var, which affects all threads but NOT in a protected, transactional way as with Refs. > 3. If this is the case, do I need to protect my def'd variables with > refs? If you want Ref-style transaction semantics, then yes. But if they are static values that don't change, then no. > 4. Is there some way to call load that ignores variable definitions > if it has already seen them but does update function definitions > regardless? Yes, use "defonce", which won't re-def things that already exist: clojure.core/defonce ([name expr]) Macro defs name to have the root value of the expr iff the named var has no root value, else expr is unevaluated > 5. Finally, in the function-def file I have an in-ns definition, not > a 'ns definition. This means that I *have* to use (import and (use, > and I can't use :import or :use, correct? Not exactly. It's true, "in-ns" takes no other arguments. But typical usage would be something like this: top-level file "my/cool/lib.clj": (ns my.cool.lib (:use ...) ; everything you need to use (:import ...) ; everything you need to import (:load "my/cool/lib/part1" "my/cool/lib/part2")) second file "my/cool/lib/part1.clj": (in-ns 'my.cool.lib) .... third file "my/cool/lib/part2.clj": (in-ns 'my.cool.lib) .... The top-level "ns" contains all the imports/uses/requires you need for the namespace, and the (:load ...) controls the order in which the subsidiary files are loaded. Each of the subsidiary files just does (in-ns ...), giving them access to everything used/imported in the top- level "ns". I forgot whether the arguments to (:load ...) need slashes at the beginning. Either way, they're inside CLASSPATH. Ok, that was a lot; I hope some of it made sense. -Stuart Sierra --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
