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
