On Wed, Mar 3, 2010 at 5:20 PM, Rick Moynihan <rick.moyni...@gmail.com>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 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
