Mark S. Miller
erights at google.com
Wed Aug 21 17:12:15 PDT 2013
On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
> On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola
> <domenic at domenicdenicola.com> wrote:
> > On Aug 21, 2013, at 18:31, "Mark S. Miller" <erights at google.com> wrote:
> >> Good idea. As a coercing function, a natural name is Promise.as(v1).
> >> as a common coercer, brevity is a virtue.
> > How about just `Promise`, following `String`, `Number`, `RegExp`, etc.?
> > (I tend to agree with Tab that both #a and #b should return a new
> > But we do need an easy coercion function, as Mark emphasizes.)
> Yeah, that's the existing coercer idiom. The other one that's close
> is Array.from(). It still always produces a new object, but that
> doesn't necessarily have to be a property of every class's usage.
> But I like just Promise(), sans "new".
Good. I like it too, and Allen's latest draft class semantics enables the
definition of classes that can do this reliably. But is there any way to
reliably polyfill this in ES5? It's not clear. For the std promise API,
given the urgency with which people want to use it *now*, I think this
polyfillability is important.
> Also, while we've settled on "resolve" still retaining its current
> semantics (promises get adopted, other values just fulfill the promise
> directly), I think the other part of Domenic's proposal - removing
> "accept" from the resolver - is still reasonable.
> There's no
> behavioral difference between resolving and accepting for .then(), so
> we don't need it there, and you already need to be careful that your
> value is wrapped in a promise for .flatMap() callbacks, so requiring
> the same for the resolver function when those are the semantics you
> want is fine with me.
I did not understand this reasoning even though I like its conclusion.
Could you expand on this, perhaps with examples? Thanks.
> We'll still need the class static for it, just not the resolver
> function. I propose we quit with the synonyms, and use Promise.of()
> like I (and others) proposed a long time ago. ^_^
I do not love this but I do not object. +0.8 ;).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss