<div class="gmail_quote">On Wed, Feb 4, 2009 at 6:04 PM, Paolo Bonzini <span dir="ltr"><<a href="mailto:bonzini@gnu.org">bonzini@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
>> Think about the semantics here for a minute: the whole concept of doing a<br>
>> #call: is that your callback is suspended, to be resumed later. I currently<br>
>> can't think of any case when you would want an ensure block *inside* a<br>
>> callback to be unwound on a #call:. Can you?<br>
><br>
> No. I can't even think of a case where you would want an #ensure:<br>
> within the definition of a flow.<br>
<br>
</div>Neither do I. Mixing #ensure: and continuations is a sure way to get<br>
either leaks or doubly released objects (which means either exceptions,<br>
or bugs too-much-reminding-of-C).<br>
<font color="#888888"></font></blockquote><div><br>That seems like "conventional wisdom" to me again. Obviously you can run into problems depending on what you put in your ensure block. But I don't yet see that:<br>
<br>self inform: 'foo'.<br>self releaseAnObject<br><br>is any less likely to cause doubly released objects than<br><br>[self inform: 'foo'] ensure: [self releaseAnObject]<br><br>Julian<br></div></div><br>