> I would have hoped that changes to refs during an transaction wouldn't > affect the in-transaction value of the ref (that is, I would have > liked the code to print 1, then 2). This way, the view of the > program's state would always be guaranteed to be consistent, even > during a transaction, and there would be no fear of non-consistent in- > transaction states breaking anything. The way it is currently work in > Clojure, though, still requires one to take all such inconsistent > states into account, rendering them effectively useless for the kind > of state management I imagined. > > (Note that I am not talking about multi-threading here; my objective > is to reduce the number of possible states in the single-threaded > case, and make sure that every computation is based upon a consistent > state.) > > Why was this behavior chosen, instead of only making changes to refs > invisible until commited (even to the transaction commiting them)? I > believe that the latter approach would actually fit better to Clojure > in general. Maybe there could at least be an alternative "dosync" form > that acts like this? > > Regards, > Denis
There are a lot of scenarios that would become difficult or impossible with the semantics you propose. On the other hand, what you want is quite simple to achieve: If you want consistent view of the the values of refs, deref them all at the start of the transaction. Stu Stuart Halloway Clojure/core http://clojure.com -- 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
