Globalization API Feedback - moar!
lukeh at microsoft.com
Wed Nov 30 15:28:32 PST 2011
>>> And further, all new functionality would need to be loaded via a module?
>> This is a strong "yes", without qualification so far in my view. We intend for built-in modules to be accessible to unversioned/pre-Harmony script via the heap (Object.system.load...).
Why should the globalization API be treated any differently? It so happens that TC39 is shepherding the development of the standard, but that need not force these APIs into a module-only API design any earlier than the rest of the browser. Given that the globalization APIs are otherwise independent of ES6, this does not seem a compelling reason to couple them to a dependency on a standard with a 1.5 year later target ratification.
Why not just pick a global name, as has been done for many new browser APIs over recent years, and then separately rationalize with modules as part of overall design of how browser and other host APIs will adopt modules?
More information about the es-discuss