On 3 November 2011 01:12, David Herman <dher...@mozilla.com> wrote:
> ES6 modules are not extensible, for a number of reasons including
> compile-time variable checking. But of course API evolution is critical, and
> it works; it just works differently. Monkey-patching says "let the polyfill
> add the module exports by mutation," e.g.:
>
> // mypolyfill.js
> ...
> if (!SomeBuiltinModule.newFeature) {
> load("someotherlib.js", function(x) {
> SomeBuiltinModule.newFeature = x;
> });
> }
>
> you instead say "let the polyfill provide the exports," e.g.:
>
> // mypolyfill.js
> ...
> export let newFeature = SomeBuiltinModule.newFeature;
> if (!newFeature) {
> load("someotherlib.js", function(x) {
> newFeature = x;
> });
> }
>
> The difference is that clients import from the polyfill instead of importing
> from the builtin module. I'm not 100% satisfied with this, but it's not any
> more code than monkey-patching.
I believe the more modular and more convenient solution (for clients)
is to create an adapter module, and let clients who care about new
features import that instead of the original builtin. With module
loaders, you should even be able to abstract that idiom away entirely,
i.e. the importing code doesn't need to know the difference. It is
easy to maintain such adaptors as a library.
This is a common approach in module-based languages. It is a more
robust solution than monkey patching, because different clients can
simply import different adapters if they have conflicting assumptions
(or, respectively, have a different loader set up for them).
One issue perhaps is that the modules proposal doesn't yet provide a
convenient way to wrap an entire module. Something akin to "include"
in ML, which is a bit of a two-edged sword, but perhaps too useful
occasionally to ignore entirely.
/Andreas
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
