I can understand why something like a clojure.lang.Volatile can be useful for some optimizations in the functions of standard library, but do they really need to become part of the public core API? Clojure is such a nice language because of the way state is handled at a higher level. Whenever I use a library, I _know_ the data I'm given is immutable. And whenever I'm given a state container such as an atom, I _know_ exactly how I can use it and, more importantly, share it. With a volatile container, I don't[1]. It's just a plain-old mutable variable, something Clojure rightfully moved away from. Sure, an API that returns a volatile should be considered a very bad practice, but I think this is still going to happen[2]. Especially by those coming to Clojure in the future with a OO background. Understanding and maintaining someone else's code might become harder as well.
Having the volatile function as part of the public core API sends the wrong message in my opinion. Could you, Cognitect, consider making the volatile related functions private, or move them to their own namespace, in order to keep Clojure more true to its nature? [1] This is also a reason why I think the idea of overloading swap! and reset! not desirable. [2] Transients don't have this problem, as they cannot escape their score. -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
