>>>>> 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. Between IE9 and IE10 PP4 we've already added 93 new global names, and other browsers are similar over the last few years. This includes some reasonably common names like "File", "URL", "AudioTrack", "ProgressEvent" and "applicationCache" which are just as likely to clash as "Globalization". I don't see any reason to believe this is going to stop anytime soon. >> 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. It's really a question of which 'we' you are talking about. The real topic that needs to get addressed is how browser APIs are going to migrate to modules. As new "HTML5" features come along or grow, are they going to use modules or are they going to continue adding global names for non-extended code consumers? I suspect that current inertia is strongly toward the latter. I see no reason why Globalization should be handled as a special case here. We should just work toward a plan for new browser APIs, and align Globalization with that plan when the time comes. >> 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. But why does it matter that TC39 is working on it vs. W3C? Why make it harder to use in the near term just because it's being shepherded by ECMA? >> 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. As far as I understand, the work on an i18n spec has always been independent of ES6. I don't mean to prejudge when either ES6 or the globalization work will be standardized, but we've agreed repeatedly on timelines for the work on the two documents that are at least a year apart. Sure - either could slip - but I don't see why we want to hold either one back from making progress unnecessarily. I don't see the discussion here as justifying on its own merits holding back any progress on the globalization APIs, including using a global name for the API as all other browser APIs will do in the same timeframe as this APIs developed. Luke _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
