On 12 December 2012 16:21, Warren Lynn <wrn.l...@gmail.com> wrote: > Although I am convinced that STM can solve things that locks cannot (See > the claim "*lock-based programs do not compose" *on Wikipedia page > http://en.wikipedia.org/wiki/Software_transactional_memory), I feel this > feature is so much over-sold. Whenever you read someone raves about Clojure > on the web, they mention "STM" as a key feature and how wonderful it is. My > own experience is similar to yours, atoms work most of the time and I also > need to use locks. I benefit more from the fact that Clojure clearly marks > what is mutable and what is not than any of those "advanced" features. >
Whilst I don't have any strong use-cases; I always felt the composability and flexibility of refs is the important feature, and is something to consider on a case by case basis. When you choose an atom you are effectively saying that nobody else will ever need to ensure consistency between this identity and another. This is fine if you're writing an application, where you can stake a claim and create an atom for global state, but what when a library you use does that? Or maybe you're writing a library? If you choose an atom, might you be forcing a decision that belongs with the application? Yes, I know Clojure libraries typically don't expose identities and state in this manner, as typically you'd just want to provide the functional stuff and let the application manage the state, but surely there are some libraries where this is done and perhaps desirable? In these cases, (do they exist?) where you want to expose an identity to others, should you not be using a ref? Rick. -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
