Killing `Promise.fulfill`

Ron Buckton rbuckton at chronicles.org
Mon Aug 19 12:50:13 PDT 2013


Promise.fulfill/PromiseSource#fulfill made sense when there was no unwrap on the input side of Promise#then:

*then:*
```js
var foreverPending = new Promise(() => {});
Promise.fulfill(foreverPending).then(x => assert(x === foreverPending))
Promise.resolve(foreverPending).then(() => { /* never reached */ });
```

*now*
```js
var foreverPending = new Promise(() => {});
Promise.fulfill(foreverPending).flatMap(x => assert(x === foreverPending));
Promise.fulfill(foreverPending).then(() => { /* never reached */ });
```

With all the changes to Promise (addition of Promise#flatMap, recursive unwrap on input side of Promise#then, etc.), it does seem that fulfill's use case has become a bit muddled. I'll admit to still being partial to the earlier design (fulfill/resolve/reject, adopt without recursive unwrap/flattening) as it was a much simpler and more straightforward API.

Ron


> -----Original Message-----
> From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of
> Domenic Denicola
> Sent: Monday, August 19, 2013 11:13 AM
> To: es-discuss at mozilla.org
> Subject: Killing `Promise.fulfill`
> 
> In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html (plus
> following errata) I created the following promise:
> 
> ```js
> var foreverPending = new Promise(() => {}); var acceptedButNotResolved =
> Promise.fulfill(foreverPending); ```
> 
> This brings up the horrible point that `Promise.fulfill(foreverPending)` creates a
> promise that is pending, not fulfilled. Argh!
> 
> There's also the issue that the distinction between accepted and resolved is not
> very useful. They are only distinguishable by flatMap, not by then, and the
> distinction that flatMap can make is confusing and doesn't seem to buy
> anything.
> 
> Tab and I think the solution to this is to:
> 
> - Kill `Promise.fulfill`, and of course also the `fulfill` option to the promise
> initializer.
> - Change `flatMap` to operate on resolved values, so that
> `Promise.resolve(foreverPending).flatMap(x => assert(x === foreverPending))`
> works.
> 
> This removes the "accepted" state entirely. It means `flatMap` effectively
> becomes a method for peeking into resolved promises and seeing what they
> are resolved to.
> 
> This also opens up the possibility of making the promise constructor go back to
> `new Promise((resolve, reject) => ...)`, in alignment with Promises/A+ and
> symmetric with `then`. The current asymmetric choice of `new Promise(({
> resolve, reject, fulfill }) => ...)` has always felt unfortunate to me.
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list