Killing `Promise.fulfill`

Mark S. Miller erights at google.com
Wed Aug 21 15:31:18 PDT 2013


On Wed, Aug 21, 2013 at 3:16 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Wed, Aug 21, 2013 at 1:57 PM, Mark S. Miller <erights at google.com>
> wrote:
> > Excellent excellent! It seems we are in agreement and clarity on all
> > terminology issue, and on almost complete agreement on substantive
> issues.
> > The only remaining issue is whether either of the following expressions
> > always return a fresh promise, and if they are exactly equivalent:
> >
> > a) Promise.resolve(v1)
> > b) new Promise(r=>r.resolve(v1))
> >
> > When v1 is a promise,
> > x) I prefer that #a return v1 and #b return a fresh promise that adopts
> v1.
> > y) You prefer that both #a and #b return a fresh promise
> > z) The fewest feasible allocations would have both return v1.
> > w) I do not expect anyone will want #a to return a fresh promise and #b
> to
> > return v1.
> >
> > We both agree that if we settle on either #y or #z, then #a and #b are
> > equivalent. Otherwise they are equivalent up to this issue.
> >
> > The reason I prefer that #b return a fresh promise is that it is
> surprising
> > for a "new" expression to return something other than a fresh object.
>
> I think it's super bizarre for a class static to act differently from
> the trivial desugaring to the same-named instance method.  (In this
> case, it's not *quite* an instance method, but close enough.  ^_^  It
> would be an instance method if we weren't caring about capability
> grants.)
>
> > The reason I prefer #a is that the primary use case for #a is coercion --
> > given possible promise v1, gimme a guaranteed genuine promise that
> > designates the same (possibly eventual) non-promise. See calls to the Q()
> > function at http://wiki.ecmascript.org/doku.php?id=strawman:concurrencyand
> > http://es-lab.googlecode.com/svn/trunk/src/ses/contract/ (which
> corresponds
> > to http://research.google.com/pubs/pub40673.html ). These calls are
> numerous
> > and necessary, and sufficiently frequent that the extra transient
> allocation
> > in the typical case will be a noticeable cost.
>
> That's reasonable, but we should do it with a different function that
> just promotes things into promises,


Good idea. As a coercing function, a natural name is Promise.as(v1). Also,
as a common coercer, brevity is a virtue.




> or leave it to library code when
> they need it.  (We don't, for example, have such an operation for
> Array/Map/Set, though I have used such an operation before.)
>
> ~TJ
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130821/838f374f/attachment-0001.html>


More information about the es-discuss mailing list