Yes, good point about loaders. I would like a standard HTML way of specifying a loader to use, so you could simply say:
<meta loader="polyfill.js"/> and from then on your clients don't have to change a thing. Dave On Nov 3, 2011, at 2:00 AM, Andreas Rossberg wrote: > 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