So what? This isn't bad. It's just what happens in implementations where you don't have timeouts enforced by the system.
C'est la vie. On Monday, August 19, 2013, Domenic Denicola wrote: > 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 > [email protected] <javascript:;> > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
