>>> 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...). This is true for ES6, but the Globalization API does not have any need to take a dependency on ES6. DOM and other host APIs regularly add new names to the global. These will need to be rationalized with modules once modules are available in engines. But I have to imagine they will continue to evolve in current form as well, including adding new global names available to non-extended JavaScript even once modules are available for consistency and developer ease. 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? Luke _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
