Globalization API Feedback - moar!

[Brendan Eich]

On Nov 30, 2011, at 3:28 PM, Luke Hoban wrote:

>>>> 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.

Not "regularly" -- irregularly and with hacks like [Replaceable]. This will stop at some point, but pushing off that date just makes more work rationalizing with modules later, and risks name collision whenever the Globalization standard actually is done.


> 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 shouldn't we stop adding new names to the global object sooner rather than later? It's a hazardous game and there's no real winner. "Globalization" is not wanted by developers or implementors as a new global property.


> Why should the globalization API be treated any differently?

Because we're working on it in the same timeframe as ES6 and we have modules in ES6.


>  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. 

Who says the globalization work is going to be standardized (December 2013 - 1.5 years is mid-2012) by next Spring?

I doubt it, given the usual contretemps, the debate on API form and function here, the need for user testing, and the two-or-more independent implementations interoperating requirement. But let's find out. There's no need to prejudge this and push hard on injecting a new name just to be independent of ES6.


> Why not just pick a global name, as has been done for many new browser APIs over recent years,

Irregularly, with collisions (even JSON), with consequent lumpy naming, incoherent name schemes, [Replaceable] hacks, etc. etc.


> and then separately rationalize with modules as part of overall design of how browser and other host APIs will adopt modules?

There's no way to ratioanalize with modules without duplication -- see the recent @object thread.

/be