The names as they exist match what's in TDPL, so they're somewhat set in stone.
Sent from my iPhone On Jan 22, 2012, at 3:05 PM, Manu <[email protected]> wrote: > On 22 January 2012 23:34, Andrei Alexandrescu <[email protected]> > wrote: > On 1/22/12 3:18 PM, Manu wrote: > On 22 January 2012 18:42, Sean Kelly <[email protected] > > <mailto:[email protected]>> 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.
