i18n API implementation issues

Allen Wirfs-Brock allen at wirfs-brock.com
Wed May 18 16:48:21 PDT 2011

On May 18, 2011, at 4:33 PM, Nebojša Ćirić wrote:

> John,
>  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.

The the cached and potentially sharable instance immutable? 

> Allan,
>  this is how current proposal looks like (just parts relevant to DateTimeFormat):
> LocaleInfo = function(settings|string) {...}
> LocaleInfo.prototype.dateTimeFormat(settings)
> LocaleInfo.DateTimeFormat = function(settings, locale) {...}
> LocaleInfo.DateTimeFormat.prototype.format(Date)
> ...
> So one can do both:
> var locale = new LocaleInfo();
> var dtf = locale.dateTimeFormat({skeleton: 'MMMy'});  // shorthand for one below
> or
> var dtf = new LocaleInfo.DateTimeFormat({skeleton: 'MMMy'}, locale});

I think you should only support one or the other (and I would go with the version on the prototype).  By having both you effective double the surface area of this part of the API., but for what benefit?  It isn't clear that the connivence in a few situations justify the cost of developers having to learn a larger API set.

Particularly if the above example is typical, I don't see why anyone would ever code the second form.  You still have to have locale available and the first form is shorter. 


More information about the es-discuss mailing list