True, though if you're using modules like that you won't need thenable assimilation anyway -- you can count on your code having native promises. If I understood Alex Russell correctly the core problem is cross-realm promise polyfillability.
It seems to me we could solve this problem by just having promise libraries monkey-patch Promise.prototype.then to assimilate. If you load a promise lib into a realm it should patch then (and then perhaps agree on some way to communicate to other promise libs not to bother patching the patch). If there's no practical issues with collision (as advocates for assimilation claim) this is an extremely low risk proposition. But again, this would be completely opt-in so your code is only affected if you *choose* to load a promise lib that does this. This solves the core issue cleanly (as put forth by Alex, at least) \without pissing in the namespace pool. On Fri, Dec 20, 2013 at 11:13 AM, Kevin Smith <[email protected]> wrote: > >> Presumably certain promise libraries would try reset the global Promise >> to AssimilatingPromise (or whatever) for full parity with polyfilled >> environments, which would be fine. >> > > If you're using modules, you wouldn't need to mess with the global object. > You could just import AssimilatingPromise as "Promise" into the current > module. The local binding would override the global Promise variable. > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
