What would you do...

[Manu]

On 9 December 2011 01:53, Sean Kelly <sean at invisibleduck.org> wrote:

> On Dec 8, 2011, at 8:23 AM, Manu wrote:
> >
> > 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...
> >
> > ...
> >
> > 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'...
> >
> > 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.
>
> 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.
>
>
> > This would seem to be a very obscure hidden bug to me. Is this a common
> pattern in D?
>
> It's probably the only case.
>
>
> > 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?
>
> See above.  MessageBox is private and receive() does the parameter
> checking.


I'm really feeling that you should add poll() and pollOnly!()() to the api.

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.
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...

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 :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111210/c55f8541/attachment.html>