On Feb 20, 10:29 am, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> Hello Rich, thanks for answering.
>
> You may not have followed the following of the thread, where I precised my
> mind by saying what I really wanted to do (but did not at first) was using
> with-local-vars, since the value to be mutated is confined in the function,
> and the macro ensures (via the use of a gensymed symbol) that only code
> generated by the macro could try to mutate the var from within the call to
> with-local-vars.
>
> So my question could be rephrased : now that there are atoms :
> * is 'with-local-vars usage deprecated ?
> * if not, what could be a typical use case for 'with-local-vars ?
> * if not, would the scenario we are talking about be appropriate for use of
> 'with-local-vars ?
>
> Thanks in advance,
>
> --
> Laurent
>
> 2009/2/20 Rich Hickey <richhic...@gmail.com>
>
>
>
> > On Feb 20, 2009, at 5:33 AM, Christophe Grand wrote:
>
> > > Laurent PETIT a écrit :
> > >> If I'm damn sure that the value will be set once from within the same
> > >> thread (here we are in the SWT UI Thread), is there a reason to
> > >> prefer
> > >> atoms ?
> > >> (This is a real question, not a disguised affirmation that I'm doing
> > >> the right thing, so please arguments welcome)
>
> > > Well I would pick atoms because I would ask myself the question the
> > > other way round "is there any reason not to prefer atoms?" and since
> > > the
> > > only reason I can think of is performance...
>
> > > You didn't choose to use an array because of its concurrency model but
> > > because its lack of and that's why, to me, it's a lower-level solution
> > > with which it's not worth to bother about unless you are forced to (by
> > > performance or interop). I understand that in this use-case you don't
> > > need concurrency but it doesn't appear to me as a sufficient reason to
> > > rule out a solution just because it happens to have a concurrency
> > > model
> > > — using an array didn't make the code simpler.
>
> > > I'm not sure I'm doing the right thing either, I'm just trying and
> > > explain how I came to the opposite conclusion.
>
> > I agree with Christophe here. Why stray from the Clojure constructs?
> > The whole point of having them is that, should you decide later to
> > have some/more concurrency, you are using safe constructs in the first
> > place. When people see them in your code they know what can and can't
> > be happening with them. And atoms are very fast.
>
> > Rich
All this made available under the EPL license here :
http://groups.google.com/group/clojure/web/swt_wrapper.clj
Cool example though, make sure that sticks around. I have referenced
4 or 5 times already.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
