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-boun...@mozilla.org] On Behalf Of
> Domenic Denicola
> Sent: Monday, August 19, 2013 11:13 AM
> To: es-discuss@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
