commit: aBlock
| result | self begin. result _ aBlock value. self commit. ^result
... and aBlock has a return. Bummer.
shouldn't that be aBlock valueOnReturnDo: [self commit] or something?
(hmm.. Squeak doesn't have that one.)
Anyway, i'll rewrite my code but I really think that "commit: [^foo]" shouldn't fail in this way...
Interesting.. I had never even considered the semantics of returning from a commit block. Maybe I was associating (confluencing) the atomicity of transactions with the execution of the block..
Anyway, i'll rewrite my code but I really think that "commit: [^foo]"
Ya know, you can do
^mySession commit: [ foo ]
and you get foo, so I guess you're saying you need to return from somewhere in the *middle* of the commit block..? I'm curious how you came to need this; guard clause?
It's probably easily fixed with an ensure: around the #commit. I'll try putting that in for the next release.
Thanks, Chris
On 11/10/05, Chris Muller chris@funkyobjects.org wrote:
and you get foo, so I guess you're saying you need to return from somewhere in the *middle* of the commit block..? I'm curious how you came to need this; guard clause?
No, in fact I didn't need the return from the block at all - the issue was easily patched by what you propose (^sess commit: [foo]). But I'm 100% sure that others will stumble into this thing, and I think that the expected behaviour of #commit: for most people would be that the commit is ensured (maybe unless an exception happens.. that's why I'm not sure that #ensure: is the correct solution).
magma@lists.squeakfoundation.org