> 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? >
Using refs throughout a library only makes sense if the library has absolutely no non-transactional side-effects (such as using any mutable Java API). There is a very narrow space where both 1) there are side effects and 2) all of them are transactional. One such example is the lamina library, which optionally supports fully transactional objects. Do note that the primary reason why the library supports both transactional and non-transactional modes is *performance*. It seems like you can't have both performance and transactions in today's Clojure. -- 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
