The existing Array.from also copies the array-like, even if it is an array. Clearly such a copying operation is useful. Whether this should be bundled into Array.from, and whether .from is the right name if it is, are valid questions.
However, my first reaction is, leave Array.from alone. It is not a coercer, it is a copier. If we are agreed not to have the Promise constructor double as the coercer (which is fine with me), then I think the coercer should be called Promise.as. Besides subjective esthetics, I'm going to add a seemingly silly "user interface" consideration: Promise.from is longer than Promise.of. For the .then-level user, they seem identical -- they have no observable difference. However Promise.from imposes a hidden storage costs which we'd like the .then-level user to avoid paying, but brevity will lead them to make the wrong choice. Promise() and Promise.as are no longer than Promise.of, and so will not lead .then-level users astray. If we do call the coercer Promise.from, as should rename the acceptor Promise.accept rather than Promise.of. If we want an Array coercer rather than an Array copier, we should consider renaming Array.from to Array.as. Although seemingly silly, I actually make the above argument in all seriousness. As Brendan says "notation is user interface." In user interface design, path-of-least-resistance matters. On Mon, Aug 26, 2013 at 1:42 AM, Domenic Denicola < [email protected]> wrote: > What do we think of having "from" be the coercer? By which I mean, change > Array.from to return its input if given a true Array (or > properly-subclassed one with [[ArrayInitialisationState]] set to true, > maybe??). Then Promise.from could follow that semantic, returning the input > if it's a true promise or coercing it otherwise. > > I can't see how this would hurt Array.from's use-case, which is usually > going to be something like `Array.from(arrayLike).forEach(…)`. And it fits > the use case promises want perfectly. > > On Aug 26, 2013, at 3:49, "Brendan Eich" <[email protected]> wrote: > > > Kevin Smith wrote: > >> I don't think you'll want to have divergent behavior for construct vs. > call with new APIs. I believe that would go against Allen's approach for > new ES6 built in classes, and beyond that, it unnecessarily overloads the > API surface. Different operations ought to have different names. > > > > +1. > > > > Date is just a botch. > > > > Boolean, Number, and String are legacy special cases, not to be imitated > by Promise (not a value type coercer when called, primitive wrapper object > constructor when new'ed). > > > > /be > > > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
