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 > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
