Globalization API: Objects needed?

Norbert Lindenberg ecmascript at norbertlindenberg.com
Sat Nov 19 19:27:10 PST 2011


Comments below.

Norbert


On Nov 18, 2011, at 16:06 , Brendan Eich wrote:

> On Nov 18, 2011, at 2:17 PM, Nebojša Ćirić wrote:
> 
>> 2. Do we keep original API (new DateTimeFormat(), and its methods) as an alternative that would let user:

I think yes.

>>  2.a. Find out if there were fallbacks through object state
> 
> That can be done by object-detecting the proto-methods too, right?

I'm not sure what you mean - how would you implement the functionality of Collator.resolveOptions without Collator objects?

>>  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?

The most common use case:

var collator = new Globalization.Collator(localeList, options);
myArray.sort(function (x, y) {
    return collator.compare(x, y);
});

This could also be written as:

myArray.sort(function (x, y) {
    return x.localeCompare(y, localeList, options);
});

but that would involve finding a cached Collator object for localeList and options for every single string comparison, and sorting an array involves many comparisons.

But there are also applications that format large numbers of numbers or dates in lists and tables, so that reusing an object would help.

Norbert



More information about the es-discuss mailing list