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
