You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm struggling to see the value in the never resolved promise approach, despite the arguments made in the linked discussion, which I think are fairly abstract. Can anyone think of a case that race([]) would happen other than in error? What do you think, @jsor, @clue?
I'm struggling to see the value in the never resolved promise approach, despite the arguments made in the linked discussion, which I think are fairly abstract. Can anyone think of a case that race([]) would happen other than in error?
Personally, I haven't had a use for the race() function so far, but this behavior is surprising to say the least, so it makes perfect sense raising this issue 👍
For bluebird it certainly makes sense to follow ES6. However, this doesn't necessarily apply to this library, considering interoperability with javascript world is a rather moot point.
I'm currently undecided, but I think we should address this somehow, docs could be a first step.
For bluebird it certainly makes sense to follow ES6. However, this doesn't necessarily apply to this library, considering interoperability with javascript world is a rather moot point.
Not sure what you are proposing by "not necessarily follow ES6": remove race or keep it in its current implementation?
Activity
jsor commentedon May 4, 2016
See domenic/promises-unwrapping#75
joshdifabio commentedon May 4, 2016
I'm struggling to see the value in the never resolved promise approach, despite the arguments made in the linked discussion, which I think are fairly abstract. Can anyone think of a case that
race([])would happen other than in error? What do you think, @jsor, @clue?joshdifabio commentedon May 4, 2016
Note that both icicle and amp throw exceptions in such cases:
https://github.com/amphp/amp/blob/v1.1.0/lib/functions.php#L388
https://github.com/icicleio/icicle/blob/v0.9.6/src/Awaitable/functions.php#L301
jsor commentedon May 4, 2016
I'd vote for either
race(), make it ES6 compliant and add a warning to the docs (example).race()in 3.0.joshdifabio commentedon May 4, 2016
What's the thinking behind removing it?Edit: The bluebird docs referenced in your post explain your reasoning.
jsor commentedon May 4, 2016
@joshdifabio yes 👍
clue commentedon May 15, 2016
Personally, I haven't had a use for the
race()function so far, but this behavior is surprising to say the least, so it makes perfect sense raising this issue 👍For bluebird it certainly makes sense to follow ES6. However, this doesn't necessarily apply to this library, considering interoperability with javascript world is a rather moot point.
I'm currently undecided, but I think we should address this somehow, docs could be a first step.
jsor commentedon May 16, 2016
Not sure what you are proposing by "not necessarily follow ES6": remove
raceor keep it in its current implementation?clue commentedon May 20, 2016
Giving I have no current use for
race(), I'm undecided.Does removing it altogether really resolve the issue here? :)
My main concern here would be lack of documentation, but I'm good with either solution 👍
Remove race()