Re: Globalization API: Objects needed?
When a caller of the Globalization API requests a locale or parameter combination that's valid but that the implementation doesn't support, then the implementation falls back to something it does support. The resolvedOptions accessor property of the constructed object provides information on what the implementation came up with, so that the caller can decide whether the fallback is acceptable or whether it wants to use alternative solutions. Examples: - A caller requests a date format for Spanish in Guatemala, and the implementation doesn't have that. The implementation might fall back to a generic Spanish (probably for Spain), or to the Spanish of big neighbor Mexico, or, if it runs on a budget cell phone designed for India and doesn't have any Spanish, even to Hindi. The caller might decide that any Spanish is OK as long as the month is spelled out (users shouldn't have to guess between day/month and month/day formats), but that Hindi needs to be worked around by loading up another date formatting library that does support Spanish. - A application for Islamic prayer times requests the Islamic calendar; if the implementation offers Gregorian instead, the application may load a library that does support Islamic. Norbert On Nov 20, 2011, at 9:59 , Brendan Eich wrote: > On Nov 19, 2011, at 7:27 PM, Norbert Lindenberg wrote: > 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? > > You wouldn't. I understood "fallbacks through object state" to mean testing > (typeof Globalization != "undefined" && Globalization.DateTimeFormat) or > equivalent, but testing for a prototype-based method can work as well. > > Clearly I misunderstood what "Find out if there were fallbacks through object > state" means. Could you give an example? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API: Objects needed?
On Nov 19, 2011, at 7:27 PM, Norbert Lindenberg wrote:
>>> 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?
You wouldn't. I understood "fallbacks through object state" to mean testing
(typeof Globalization != "undefined" && Globalization.DateTimeFormat) or
equivalent, but testing for a prototype-based method can work as well.
Clearly I misunderstood what "Find out if there were fallbacks through object
state" means. Could you give an example?
>
>>> 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.
Thanks, that all makes sense.
As Alex Russell pointed out, the DOM has default locale information induced by
the browser and document. Making localeList an explicit parameter may just be
burdening typical JS G11n code with having to acquire and then pass around the
same information that (once control flows back into a DOM method that is *not*
parameterized that way) is recovered from the default DOM information. If this
is true, then it could be worth catering to the default locale(list).
Hope I'm understanding this stuff -- corrections welcome.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API: Objects needed?
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
