i18n API implementation issues

Nebojša Ćirić cira at google.com
Wed May 18 16:33:20 PDT 2011

 I think you are correct. We allow for cached items, so it wouldn't be "new"
object we return in that case. I guess it's better to leave names as they
are now.

 this is how current proposal looks like (just parts relevant to

LocaleInfo = function(settings|string) {...}
LocaleInfo.DateTimeFormat = function(settings, locale) {...}

So one can do both:

var locale = new LocaleInfo();
var dtf = locale.dateTimeFormat({skeleton: 'MMMy'});  // shorthand for one


var dtf = new LocaleInfo.DateTimeFormat({skeleton: 'MMMy'}, locale});

18. мај 2011. 16.11, John Tamplin <jat at google.com> је написао/ла:

> On Wed, May 18, 2011 at 6:35 PM, Nebojša Ćirić <cira at google.com> wrote:
>> 4. Should we rename LocaleInfo.*collator*()/*numberFormat*()/*
>>> dateTimeFormat*() into LocaleInfo.*createCollator*()...? It makes it
>>> clear we are creating new object.
>>> The methods on the LocaleInfo constructor or are they really
>>> LocaleInfo.prototype methods.  In other words are the results derived from a
>>> specific LocaleInfo instance or is the result some sort of global value that
>>> is independent of the instances. If the latter, why are they associated with
>>> the LocaleInfo constructor?
>> They are prototypes:
>> LocaleInfo.prototype.collator()
>> I propose
>> LocaleInfo.prototype.createCollator()
>> since they actually create a new LocaleInfo.Collator (or DateTimeFormat or
>> NumberFormat) objects based on that locale info.
> Are they required to create new instance, or can they return a cached
> object that uses the same parameters?  If the latter, then I would suggest
> either foo() or getFoo() rather than createFoo().
> --
> John A. Tamplin
> Software Engineer (GWT), Google

Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110518/8ec1531e/attachment.html>

More information about the es-discuss mailing list