Choosing Globalization API namespace

Brendan Eich brendan at
Thu Nov 17 14:25:10 PST 2011

On Nov 17, 2011, at 2:18 PM, Nebojša Ćirić wrote:

> Looking at the
> 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') {

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.


> 17. новембар 2011. 13.14, Brendan Eich <brendan at> је написао/ла:
> 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 on how the system loader, or the system modules, are reflected into legacy script without injecting new globals. Object.system as the system loader reference is one idea. Then you might wire up Object.system.load("@g11n"...) or whatever the right module loader API is.
> /be
> -- 
> Nebojša Ćirić

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list