That really helped out a lot, thanks guys!

As long as we are on the subject of helping out newbs...

I like to program from the repl.

I have a namespace that maintains some state, mainly integration with
openGL.  It has some essentially static variables that can't get
initialized until openGL is initialized (like recording the version,
vendor, extensions, and the renderer).

I have put everything ui-related in one namespace called
lambinator.ui.  I have split this namespace up into two files, on for
variable definitions and another for function definitions.  The reason
is that I usually don't want my variables cleared when reloading the
file through load-file using the repl.

I am using simple def's to define the variables; the ones that may be
changed through opengl callbacks on other threads I am protecting with
refs.

So to be clear, I have:

<main-ns-file> -> this contains defs and calls "load" on the function
file
<function def file> -> this gets loaded all the time when I am working
in the repl.

1.  Is using defs the best way to go about this?  They are global
variables; they model static state of the system, essentially.  I
might associate them with the main window, however, instead of global
defs like they are now.
2.  How do defs handle updating when I reload a file in the repl and
then something in some other thread triggers a render?  Lets say I
change the render function which is called from the GLEventListener
object on display.  It is defined through a simple defn.  Does this
change propagate through to the other threads?  Are defs themselves
protected if they are at the module/file level?  I was thinking maybe
all the threads shared an environment which is itself a functional
datastructure protected by refs...
3.  If this is the case, do I need to protect my def'd variables with
refs?
4.  Is there some way to call load that ignores variable definitions
if it has already seen them but does update function definitions
regardless?
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?  The documentation for in-ns
didn't indicate that the keyword options were viable or I missed that
piece of info.  An answer to 4 would make 5 irrelevant.

Again, thanks to everyone for their replies!

Chris

On Dec 20, 9:53 am, Stuart Sierra <the.stuart.sie...@gmail.com> wrote:
> This might make a good FAQ question:
>
> On Dec 20, 11:25 am, chris <cnuern...@gmail.com> wrote:
>
> > I am unclear as to the difference between refer, import use, and require.
>
> Hi Chris,
>
> require: Load a Clojure library from a file on classpath.  Use this
> when you want to load a library, but leave it in its own namespace.
>
> refer: Bring public symbols from one namespace into the current
> namespace.  Use this when a library has already been loaded (example:
> clojure.set) but you want to use its public symbols without a
> namespace qualifier.
>
> import: Copy Java class names into current namespace.  Use this when
> you want to use a Java class without typing the full package name.
>
> use: Combination of require and refer.  Use this when you want to load
> a library AND use its symbols without a namespace qualifier.
>
> All four are available as keyword arguments to "ns", which is the
> preferred way to use them:
>
> (ns foo.bar
>   (:use my.little.lib)
>   (:require clojure.contrib.duck-streams)
>   (:import (java.io File InputStream))
>   (:refer clojure.set))
>
> ":require" also allows aliasing, like this:
> (ns foo.bar
>   (:require [clojure.set :as set]))
>
> Now you can write the symbol "clojure.set/union" as "set/union".
>
> -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
-~----------~----~----~----~------~----~------~--~---

Reply via email to