Hi Stefan,
thanks for your interest. let me explain further...
1. I did start with a design that involved a map (the bank) full of
agents (accounts). Then I switched to a map full of atoms thinking that
I don't really need asynchronous operations. I settled to the single ref
approach because it seemed like an overkill to have all these refs
inside. Your comment however does make sense...Since there is a single
identity, perhaps STM is an overkill...
2. can you ellaborate why you think this is debatable? All the
ref-managing fns return the in-transaction value of the ref (i.e.
'alter'). My problem was with 'doseq' which returns nil so I followed
the general approach of returning the in-transaction value of the ref
after it commits.
3. As I understand it these 2 transactions will be composed/merged into
a single transaction. Again, originally I had a bare 'alter' (no dosync)
on the private fn transfer1 simply because it is hidden and not supposed
to be used...think of it as a helper fn for 'transfer'. but then I read
somewhere that transaction can be nested without a problem so I thought
it is safer to include 'dosync' in tranfer1 as well...
I'm not getting you wrong, don't worry...this is the reason I started
this thread - need some answers /feedback :)
Jim
On 21/11/13 10:42, Stefan Kamphausen wrote:
Hi,
I may be missing something here, since this thread leaves me a bit
confused.
1. Why are you using a Ref for the bank in the first place? It is a
single identity and thus should be an atom, because you do not need to
coordinate changes of at least two identities.
If I am not mistaken, the generic bank transfer example is to have a
Ref for each of the accounts and to make sure, that there is never a
state of the world in which the money is missing or is available twice.
2. "Even our side-effecting fns return something (per alter) which is
good." -> That seems debatable to me.
3. Why do you nest transactions on the same Ref in transfer1 and transfer?
Don't get me wrong, what you're doing may be fine. In that case, I
just don't get it. Which, in turn, may be a relevant feedback to you,
since this is to be educational :-)
Kind regards,
Stefan
--
--
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/groups/opt_out.
--
--
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/groups/opt_out.
