s "binding"
code to changes in declared items, making it a reactive, event based
system for handling GUIs. I have not used
it though...
Interop with Clojure is definitely an interesting intellectual exercise.
pinocchio
--~--~-~--~~~---~--~~
You received
editor
which helps write logically convolved code better (actually a great
talk...).
I would love to see an editor like _that_ for clojure :)
Pinocchio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojur
bal variables... in such a
case, factor only buys you anonymous global variables potentially
avoiding naming conflicts ;).
pinocchio
P.S. The argument about expressiveness is generally very subjective
besides some glaring violations (dare I bring C++... ;) ).
P.S(2). Disclaimer: haven't don
n do we still
have a problem? Is this a valid way to handle "internal" mutable state
which is not encapsulated in closures?
So can we conclude that atoms with atom-set can be freely used in
functions which don't return closures around them and if we really need
to do that, we sho
n in the
> context of a particular user's session. Another area where
> continuation-based actions are useful are multi-step flows, which are
> present in every web application (think checkout process for example, or
> login/signup).
>
> So, these actions make developin
of the global and thread
local namespace should reduce implementation hassles a lot.
I will really appreciate some comments.
Pinocchio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To pos
od fit for GUI programming.
It may be possible to do something similar by adding optional "hook"
functions with the swing component wrappers which trigger on
PropertyChangeEvents from swing components. I have not tried implementing
this but I think that hiding these details behind the syn