Why isn't `Promise.all()` overloaded?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why isn't `Promise.all()` overloaded?

Jacob Pratt
This is potentially a very simple question, `Promise.all()` takes a single iterable as a parameter. Is there any particularly reason it wasn't overloaded to allow passing multiple parameters (and use `...arguments`)? Of course, the only difference is the creation of an array, but it is an array that doesn't need to be created.

Jacob Pratt

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why isn't `Promise.all()` overloaded?

Tab Atkins Jr.
On Fri, Aug 10, 2018 at 2:30 PM Jacob Pratt <[hidden email]> wrote:
> This is potentially a very simple question, `Promise.all()` takes a single iterable as a parameter. Is there any particularly reason it wasn't overloaded to allow passing multiple parameters (and use `...arguments`)? Of course, the only difference is the creation of an array, but it is an array that doesn't need to be created.

API complexity - Promise.all()'s promise resolves to an array of
resolved values. How would multiple input iterables be reflected here?
Just concatenated together? More straightforward and predictable to
just ask the user to concatenate things on the input side.

Also, Promise.all(), following the example of other promise methods,
doesn't require the values in the input array to be promises; it just
Promise.resolve()'s all of them, so you can pass in non-Promise values
as well.  With a "multiple input arguments" API shape, it's less clear
that `Promise.all("foo", "bar")` is wrong, for instance (it would
treat each of them as a 3-element array of characters).  With the
current design you usually have to put in a literal [], so it's easier
to remember the API shape.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Why isn't `Promise.all()` overloaded?

Jordan Harband
In addition to what Tab said, it produces a Promise for an iterable (that happens to be an array), so it makes perfect sense that it takes an iterable of the same number of items, so there's a 1-1 mapping.

On Fri, Aug 10, 2018 at 3:02 PM, Tab Atkins Jr. <[hidden email]> wrote:
On Fri, Aug 10, 2018 at 2:30 PM Jacob Pratt <[hidden email]> wrote:
> This is potentially a very simple question, `Promise.all()` takes a single iterable as a parameter. Is there any particularly reason it wasn't overloaded to allow passing multiple parameters (and use `...arguments`)? Of course, the only difference is the creation of an array, but it is an array that doesn't need to be created.

API complexity - Promise.all()'s promise resolves to an array of
resolved values. How would multiple input iterables be reflected here?
Just concatenated together? More straightforward and predictable to
just ask the user to concatenate things on the input side.

Also, Promise.all(), following the example of other promise methods,
doesn't require the values in the input array to be promises; it just
Promise.resolve()'s all of them, so you can pass in non-Promise values
as well.  With a "multiple input arguments" API shape, it's less clear
that `Promise.all("foo", "bar")` is wrong, for instance (it would
treat each of them as a 3-element array of characters).  With the
current design you usually have to put in a literal [], so it's easier
to remember the API shape.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss