On Nov 30, 2011, at 7:14 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. > > Between IE9 and IE10 PP4 we've already added 93 new global names, and other > browsers are similar over the last few years.
s/few/many/ :-|. Playing catch-up doesn't equate to high rate of addition averaged over all browsers across the last five years. But (more below) the pipelining among standards bodies means we'll have to get modules proven with some built-in examples first, within Ecma TC39, before we get W3C to take a dependency. > 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. It will slow down (has slowed down) now that the bulk of "HTML5" (including Web API / DOM Core) is done. Anyway: 1. We had real problems with JSON, also with other names. Forcing overlong and ugly names doesn't do anyone any good. 2. The core language is not the DOM or Web APIs writ large. If we're adding modules we could take a dependency. It's not a non-starter just because of the global name hacking needed so far in lieu of modules. >> 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. Gee, that sounds like what I was saying. Are you assuming the alignment comes after the Globalization spec is gunned through Ecma? While perhaps at the same time sandbagging the plan for new browser APIs? Excuse my cynicism. Inertia is a fact, but why are you embracing it so hard? Getting modules prototyped will take effort and it's easy to starve that initiative by doing more API hacking, ad nauseum. >>> 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? Because, for one thing, the W3C and other groups so far produce specs that reference published Ecma specs. They do not take dependencies on drafts. Another reason is that we are all (TC39 proper and the Globalization group) meeting every two months and discussing things here, so rationalizing Globalization as a built-in module looks like a good first test case for "the plan". It avoids the inter-standards-body lawyering, latency, and culture clash problems. >> 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. No. At the last TC39 meeting I dissented from the optimism about next Spring (no one mooted next December). We have not all agreed. Anyway, who cares what you or I project? No one has a crystal ball. We're here to talk about substance, not speculate about schedule. If we have a chance to avoid yet another global name injection because we're doing exactly the same thing -- using built-in modules -- in the same spec-drafting time frame as for other ES6 additions, then we ought to consider doing likewise for Globalization. I'm not sandbagging the Globalization work, far from it. If it is all but done and the plan to align built-in modules is not at the same roughly ready state, then we should let inertia have a last hurrah -- provided no one has already played unfairly. > Sure - either could slip - but I don't see why we want to hold either one > back from making progress unnecessarily. At this point, nothing is held back by mocking up Globalization as a built-in module. That was trivially stubbed already, from the earlier thread on this topic. The deeper issues, which Nick Zakas and others have raised, remain the API form and function. We need to settle those instead of overdoing the inertia argument here. Window dressing as built-in module or as pseudo-module namespace object is a sideshow. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
