I don't follow your logic. Modifications of refs within a transaction retry too.
On Mar 5, 11:56 am, Mark Engelberg <[email protected]> wrote: > On Wed, Mar 3, 2010 at 5:20 PM, Rick Moynihan <[email protected]>wrote: > > > > > If you have a single value representing the whole world, then it seems > > that protecting it with an atom would be the simplest and most > > idiomatic solution. > > ... > > > For a single value > > there seems to be little reason to adopt refs, ... > > I disagree. The problem with atoms is that updating an atom is a > side-effect that cannot (typically) participate safely in a transaction. It > might be retried, so if for example, you want to increment the contents of > an atom, it might get incremented multiple times which is generally not okay > (if you're storing something in a cache, then a retry might be okay). > > If you make a design decision to use an atom, you are effectively committing > to never, ever being able to update that atom within a transaction. > > In my opinion, this has major implications and is a decision that should not > be taken lightly. In a language like Clojure, we should strive to write > things that are as side-effect free as possible, so they can participate in > transactions. Using atoms runs the risk of creating headaches later, so > unless you're 100% sure the semantics of your program won't change if they > are retried, or if you're 100% sure you'll never want to change the contents > of the atom as part of a sequence of logic involving setting other refs, > don't use atoms. > > refs can do everything atoms can do and more. They are slightly slower, > perhaps, but much safer. So unless you have an explicit performance reason > to use atoms and have thought through the implications, the simplest design > choice is to prefer refs. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
