Message-Passing

[Manu]

On 22 January 2012 23:34, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org
> wrote:

> On 1/22/12 3:18 PM, Manu wrote:
>
>> On 22 January 2012 18:42, Sean Kelly <sean at invisibleduck.org
>>
>> <mailto:sean at invisibleduck.org**>> wrote:
>>
>>    The popularity of a language has no bearing on the quality of one of
>>    its features. Are there other message passing schemes you prefer?
>>
>>
>> As said in the original post, I think receiveOnly() is the most
>> intuitive API. I just think that one should be named receive(), and
>> perhaps receive() may be renamed receiveMulti(). Surely that would be
>> more intuitive to more people?
>>
>
> Names will not change.


Why? Surely API's being as intuitive as possible should be a key goal for a
standard library?
The thing isn't supposed to be stable yet is it? If you take the attitude
that no name should ever be changed, then I think there is a problem with
the phobos contribution process.
Phobos contributions have basically no incubation time/process. I've seen
others suggest new stuff should go in exp.xxx to incubate, and it should
only be promoted to std after some time, or some successful usage in
multiple large-ish projects?
It's a shame that basic usability things like that couldn't be caught
earlier.

Do you disagree that receive() and receiveMulti() (with the crazy
var-arg-of-delegates API that nobody would have ever seen in any popular
language before) is a far more intuitive approach?
C# is awesome because it gets this right. I think that's its single
greatest achievement, and can not be understated.

Also both Only and Multi varieties should have a Timeout version, and I
>> would love to see a poll()/pollMulti() function.
>>
>
> This is sensible. You may want to add functions through pull requests, or
> make enhancement requests on bugzilla.
>

Shall do one or the other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120123/3a1a31b4/attachment.html>