Globalization API working draft

[David Herman]

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 <dherman at 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