Choosing Globalization API namespace
On 17.11.2011 22:07, Nebojša Ćirić wrote:
HI all, we briefly discussed the i18n namespace at the meeting yesterday. It seems that "Globalization" (current proposal) could conflict with jQuery plugin, and also some members were worried about the actual name length.
Unfortunately I hadn't an ability to follow in detail about this proposal (will check it later).
Anyway, the "Globalization" name itself seems too long for me (yes, we all have autocomplete in editors, but nevertheless).
What about "Locale"?
P.S.: Having a similar module in one of my projects I used directly "i18n" name. E.g. i18n.translate('welcome').
Dmitry.
I feel the actual name was less of a problem for the committee, they were more worried about possible conflicts, and wanted to make sure that we place our library so that it can't conflict no matter what name we pick.
There are couple of names floating around (including i18n, World, Text). Locale has a more low level meaning (usually a class that maintains locale information), so it could confuse developers. Most of ad hoc members would like to skip i18n, l10n, g11n kind of names (I'll let Norbert explain the reasoning).
- новембар 2011. 10.19, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> је написао/ла:
On Nov 17, 2011, at 10:07 AM, Nebojša Ćirić wrote:
HI all, we briefly discussed the i18n namespace at the meeting yesterday. It seems that "Globalization" (current proposal) could conflict with jQuery plugin, and also some members were worried about the actual name length.
Somebody mentioned we should wait for module implementation/spec to settle, but I don't think that would be reallistic if we were to start working on i18n API prototype(s) in the near future.
Modules are being prototyped in the near future, so there's nothing drastically less realistic about depending on some spec draft provision. It could change, but you could also bootstrap it in JS and not even wait for the concurrent module system prototyping to get that far.
What do you think would be a good alternative (Object system was mentioned, but I would need more deatails there)?
No, that is the "use the module system" idea. We need to agree
Looking at the harmony:modules_examples:
module i18n from '@Globalization'
is how modules are going to work in the future.
What you propose in the mean time is to define Object.system.load(...) method (Latest Chrome doesn't have Object.system, so that would need to be defined too).
The load method could return a reference to the hidden global object like: var i18n = Object.system.load('Globalization');
In our case, we already have v8Locale global so load would:
Object.system.load = function(name) { if (name === 'Globalization') return v8Locale; return undefined; };
Am I getting this right?
- новембар 2011. 13.14, Brendan Eich <brendan at mozilla.com> је написао/ла:
On Nov 17, 2011, at 2:18 PM, Nebojša Ćirić wrote:
Looking at the harmony:modules_examples:
module i18n from '@Globalization'
Nit: we've been using '@lowercase' convention, ideally with a single lower-case word, in naming built-ins.
is how modules are going to work in the future.
Yes, which is why we are talking about how the system loader or something equivalent for our purposes (the set of all system [built-in] modules) is made available to unversioned script.
What you propose in the mean time is to define Object.system.load(...) method (Latest Chrome doesn't have Object.system, so that would need to be defined too).
(No one has implemented any such thing, because it hasn't been proposed in detail yet such that a draft ES6 spec could try to specify it.)
The load method could return a reference to the hidden global object like: var i18n = Object.system.load('Globalization');
Nit: still would want the @, so '@globalization' or something shorter. '@locale'?
In our case, we already have v8Locale global so load would:
Object.system.load = function(name) { if (name === 'Globalization') return v8Locale; return undefined; };
Am I getting this right?
That's a good start at a shim hack. Better still would be to work incrementally to eliminate the v8Locale global property.
The module loader load method, IIRC, takes a callback that is invoked with the module object passed as the sole parameter. This is necessary for loading modules from "slow media" (filesystem, web, etc.), but for a built-into-the-browser system library, perhaps it could be avoided. Anyway, from what I recall of the module loaders API, you'd want:
Object.system.load = function(name, callback) { if (name === 'Globalization') { callback(v8Locale); } };
The burden is
Nit: still would want the @, so '@globalization' or something shorter. '@locale'?
I was just making sure I got your idea right. I'll use @ in the future.
That's a good start at a shim hack. Better still would be to work incrementally to eliminate the v8Locale global property.
Chrome loads v8 extensions on startup (and i18n is one of those), so v8Locale becomes available from get go. I expect that behavior to go away with further development of the module system.
The module loader load method, IIRC, takes a callback that is invoked with the module object passed as the sole parameter. This is necessary for loading modules from "slow media" (filesystem, web, etc.), but for a built-into-the-browser system library, perhaps it could be avoided. Anyway, from what I recall of the module loaders API, you'd want:
Object.system.load = function(name, callback) { if (name === 'Globalization') { callback(v8Locale); } };
The burden is on us in TC39 to get module loaders and such spec'ed harder, drafted, and then prototype-implemented. But if you can play along, it shouldn't require more than a little shimming IMHO.
Callback sounds good. Even for system libraries you may encounter delay if engine decides to load them on demand (say from dll).
we briefly discussed the i18n namespace at the meeting yesterday. It seems that "Globalization" (current proposal) could conflict with jQuery plugin, and also some members were worried about the actual name length.
Somebody mentioned we should wait for module implementation/spec to settle, but I don't think that would be reallistic if we were to start working on i18n API prototype(s) in the near future.
What do you think would be a good alternative (Object system was mentioned, but I would need more deatails there)?