>
> I highly doubt that will be possible -- experience strongly suggests that
> every odd feature _will_ be relied on in the wild by that time. If we think
> thenable assimilation is a problem then we have to remove it now. I, for
> one, would welcome that. We could still provide an _explicit_ thenable
> adaptor method in the Promise API.
Agreed 100%. I'm skeptical that we've really done our homework analyzing
the backward compatibility constraints for this design.
Now that we have a proper cross-realm nominal Promise type (which we didn't
have before), the right thing to do is to use nominal typing. We should
have started from that point and then figured out how current thenables can
cope.
Too late?
Probably, but just for kicks, here's another solution:
Provide a Promise subclass, BorgPromise (Star Trek reference) which does
simple thenable coercion in its then function (no funky WeakMap). All
libraries which might interact with thenables switch to using BorgPromises.
At some point in the future usage of non-Promise thenables will approach
insignificance, at which time BorgPromise libraries can freely switch to
using regular Promises, and assimilation can fade into history.
BorgPromise doesn't even have to be specified by TC39. It can be a user
library:
// Remove this line sometime in the future...
import Promise from "package:borg-promise";
// package:borg-promise
class BorgPromise extends Promise {
then(onResolve, onReject) {
if (typeof onResolve !== "function") onResolve = x => x;
return super.then(x => {
// NOTE: x is a non-promise
return isThenable(x) ?
x.then(onResolve, onReject) :
onResolve(x);
}, onReject);
}
}
export { BorgPromise as default };
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
