<div class="gmail_quote">On 9 December 2011 01:53, Sean Kelly <span dir="ltr"><<a href="mailto:sean@invisibleduck.org">sean@invisibleduck.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Dec 8, 2011, at 8:23 AM, Manu wrote:<br>
><br>
> Just digging through concurrence.d since the docs are pretty bare, and I've come across this pattern, which raises a pretty worrying alarm to me. I wonder if this is common in D libraries...<br>
><br>
</div>> ...<br>
<div class="im">><br>
> No overload, receives a tuple, and assumes that static-if the first tuple item is IMPLICITLY CONVERTIBLE to a Duration, I must be calling the 'overload'...<br>
><br>
> I guess this means I can never pass a Duration in a message to the non-timeout receive()... or anything that is implicitly convertible to a Duration.<br>
<br>
</div>Right.  The only thing you can pass to receive() are functions taking one or more parameters.  mbox.get() itself is actually pretty lax in enforcing this because it relies on the caller to do most of the filtering (via checkops).  This should be safe since the mbox itself is private.  I suppose I could have done this a different way, but overloading when one function has (T…) args is a bit weird.<br>

<div class="im"><br>
<br>
> This would seem to be a very obscure hidden bug to me. Is this a common pattern in D?<br>
<br>
</div>It's probably the only case.<br>
<div class="im"><br>
<br>
> I certainly wouldn't want to be tracking down this bug on build night... Is there something I've missed here? Some sort of safeguard I've overlooked?<br>
<br>
</div>See above.  MessageBox is private and receive() does the parameter checking.</blockquote></div><br><div>I'm really feeling that you should add poll() and pollOnly!()() to the api.</div><div><br></div><div>For my money, the receive() API is extremely obscure (and not documented, impossible to work out what it's supposed to do. I found some example and even then only realised what was happening after staring at it for 10 minutes... I just never imagined anything like that, and couldn't even see it when I was staring at it). I would imagine it's almost never what you actually want. I suspect receiveOnly would get called 99% of the time.</div>
<div>That said, receiveTimeout (necessary to poll) only implementing the receive() style api is a bit inefficient, particular when I don't want to specify a timeout at all anyway, just 0 to do a poll...</div><div><br>
</div><div>I'm also thinking that the name 'receive' should be the sensible function (receiveOnly), and the super complex one with all the callbacks should have the obscure name, but I imagine it's impossible to change now :(</div>