On Thu, Sep 13, 2012 at 12:56:47PM -0400, Chas Emerick wrote:
One of the great advantages of Ring (and other purely functional bits
that stack on top, like Compojure, Bishop, etc) is that its handlers
are readily composable. Among other things, this means that way you
compose handlers from
From what I've heard, you are absolutely right on those globals. It isn't
considered idiomatic and should be avoided, like in all other languages.
The singleton analogy fits pretty good.
Some advice on how to encapsulate state in a sane way can be found for
example here:
If I'm right then defining your 'globals' (for lack of a
better word) like this would mean, among other things, that you really can't
have two independent Noir apps defined/running in the same project - is that
a correct assessment?
Just out of curiosity, could you expand on what you mean
On Sep 13, 2012, at 11:57 AM, Mark Rathwell wrote:
If I'm right then defining your 'globals' (for lack of a
better word) like this would mean, among other things, that you really can't
have two independent Noir apps defined/running in the same project - is that
a correct assessment?
Just
One of the great advantages of Ring (and other purely functional bits that
stack on top, like Compojure, Bishop, etc) is that its handlers are readily
composable. Among other things, this means that way you compose handlers
from two different namespaces in the same app is fundamentally no
Hello,
So I've been working on a project at work, that required me to code a
simple web interface. I considered going with Noir, and while reading the
code, I noticed a pattern that seems to repeat throughout most of the code
that Chris Granger has published in Clojure. This is what I'm
defonce simply means do not bind the var if it already has a root
value... I think it only applies when reloading your namespace...to be
honest, I'm not sure why Chris has coded it like that (creating an atom
is not really expensive), but i find it hard to believe that you can' t
have 2 Noir
Sorry I wasn't more clear - I'm not talking about defonce, but about having
refs (atoms) defined at the top level. When they're defined like this, they
basically become global variables, don't they? Having two Noir apps would
then mean they share the same routes, among other things. Or am I
aaa ok I see what you mean...well, yes everything starting with def can
be considered a 'global' var or even better a namespaced var (not really
a variable in the traditional sense)...In Noir's case most of the atoms
are maps so it could be that each Noir app registers its specific routes
on a
I find myself having to make similar choices quite often in my own
Clojure code - do I create perhaps a map of things that represent some
kind of 'state' and pass that around to each function that needs it,
or do I do what has been done above and create some vars in a ns where
most (all?) the
What I usually do when I want to avoid passing these implicit parameters is
just use thread-local bindings with ^:dynamic vars. From the point to
rebind them using (bindings), every function called from within the binding
block sees the same value; you can combine them with atoms/agents/refs
On 12/09/12 16:29, the80srobot wrote:
What I usually do when I want to avoid passing these implicit
parameters is just use thread-local bindings with ^:dynamic vars. From
the point to rebind them using (bindings), every function called from
within the binding block sees the same value; you can
On 12/09/12 16:23, gaz jones wrote:
I find myself having to make similar choices quite often in my own
Clojure code - do I create perhaps a map of things that represent some
kind of 'state' and pass that around to each function that needs it,
or do I do what has been done above and create some
13 matches
Mail list logo
