> > 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.
> > 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. I agree. At first I was always mixing and matching atoms and refs, but it seems like a case of premature optimization. If I understand correctly atoms don't give you any benefit over refs besides performance. As you grow a program it's virtually impossible to predict which variables will end up needing coordinated updates, so why not just use refs and count on the STM for everything by default? Once you get to the performance optimization phase you can start converting refs to atoms, add type hints where appropriate, and make use of transients in your inner loops. The ref->atom refactoring would be very cool, and if you start by using refs for everything it would be easy as a first pass to turn any ref that is always modified alone into an atom. -Jeff -- 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
