On Nov 18, 2011, at 2:17 PM, Nebojša Ćirić wrote: > I think that we have agreement on being able to set global locale and to move > locale list into options (anybody against?). > > I have couple questions with toLocaleString approach: > > 1. Who imports the @g11n module in this case? Implementation (under which > name) or the user (what happens if they don't, and then try to use > toLocaleString)?
Module users name the module, that allows composition in any scope with user-managed names to avoid conflicts. However, we're talking about built-in methods of Number.prototype, Date.protoytpe, etc. -- these can be predefined as if the module were declared by a standard prelude. Would a self-hosted @g11n module monkey-patch these built-in prototypes using ES5 Object.defineProperty? It could, I'm just asking because there are several alternatives: A. We make the new Globalization API part of ECMA-262, or normatively required by referencing a separate standard, so these methods should be observably present from the earliest possible observation point (script or event handler execution). B. We do not make the new G11n API normative/required, so developers will want to object-detect the absence of such prototype methods and polyfill an ES5 self-hosted implementation (large collation table issue TBD). > 2. Do we keep original API (new DateTimeFormat(), and its methods) as an > alternative that would let user: > 2.a. Find out if there were fallbacks through object state That can be done by object-detecting the proto-methods too, right? > 2.b. Apply format repeatedly using the same options (internal caching may > remove this requirement) That seems like it could be a valid use-case in its own right, even with caching. Can you show code written both ways that makes realistic re-use of the object? > 3. Does it make sense to hang Collator on String or any other built-in type? > 4. Would we hang calendars in the future on Date? I don't think so, but we should discuss. It's better to avoid injecting globals, which led ES5 to extend Object and Array a bit with new "static methods". But with a module, top-level functions can be exported from the module, without polluting the global scope. The module client names the module and uses dot to reference the imports, or imports the exports into local names directly referencing the functions. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
