Am 23.09.2011 17:25, schrieb Stuart Halloway:
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.
Do you have an example?
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.
Fair enough, but if a transaction is split among several functions, this
becomes difficult.
Regards,
Denis
--
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
