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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
