Killing `Promise.fulfill`

Domenic Denicola domenic at domenicdenicola.com
Mon Aug 26 01:42:26 PDT 2013


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" <brendan at mozilla.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 



More information about the es-discuss mailing list