Globalization API Feedback - moar!
cira at google.com
Fri Dec 2 11:56:31 PST 2011
I was always pro that (have a cake and eat it too) approach, but some TC39
members were against having 2 ways of doing things (complicates the API). I
think that functional approach could reuse the object-based implementation
with addition of caching to lower the costs.
At this point we have 3 proposals:
1. Tie in to toLocaleString type of methods
2. Functional proposal
3. Object-based proposal
I think 1. suffices for a casual user that doesn't care about what got
resolved to what, and which locale or pattern fallback was used.
We could expose either 2. or 3. to an advanced user who needs more control.
Now, if 1. is sufficiently functional (it's built in anyways), then I would
go with exposing 3. as is more efficient in general use case.
Keeping all 3 around would be too much.
02. децембар 2011. 11.36, Brendan Eich <brendan at mozilla.com> је написао/ла:
> Could we not have both object-based (to amortize construction cost) and
> functional (with cached object) flavors? Win-win, and lots of precedent in
> various libraries going back to POSIX era libc IIRC.
> On Dec 2, 2011, at 10:20 AM, Nebojša Ćirić wrote:
> I know this is related to the actual implementation, but there are some
> things we won't be able to avoid if we go with new (functional) API. If
> performance penalty is acceptable then we should proceed with the
> 1. Single format/comparison operation - performance should be mostly the
> same for both (most of the time would go into creating the support object -
> say ICU collator)
> 2. Multiple format/comparison invocations - performance should be on the
> side of object like API, the question is just how much
> 2a. Both approaches have to create supporting object and process
> options, but object approach does that only once
> 2b. Functional approach would have to cache objects, which should help,
> but in that case it would need to generate hash keys from given options
> I wrote a short benchmark (JS code only) to see how much hashing
> influences the performance. Please take a look at the results and the code
> (any optimization hints are welcome).
> Code (formatter is intentionally trivial in both cases):
> 01. децембар 2011. 11.53, Brendan Eich <brendan at mozilla.com> је
>> On Nov 30, 2011, at 11:37 PM, Brendan Eich wrote:
>> On Nov 30, 2011, at 10:25 PM, Anton Yatsenko wrote:
>> In case I've missed point — sorry.
>> There are several points. How one gets the Globalization "module" is one,
>> but the bigger points at issue involve API parameterization, overhead, and
>> style issues.
>> Also, critically (Shawn Steele's latest post, cited in full below, hit
>> this point) "support inference" or in general, whether and how fallback
>> Furthermore some implementations succeed for *any* input locale. In
>> those cases DateTimeFormat could succeed for any input RFC4646 string.
>> Many of those may fall back to non-specific data, but it is possible for
>> getSupportedLocales to succeed for all of those.
>> It might be more practical to have a "getExplicitLocales" for the locales
>> that the system has explicit information for, but I'm not sure how that'd
>> be helpful. In Mark's case "de" might be the explicit locale that supports
>> the collator but your application would somehow have to infer that "de"
>> might also be useful for de-*. Furthermore, if Mark had a "de" collator,
>> and generic Number/DateTimeFormats, but additional specific de-AT and de-CH
>> Number formats, then he might return de, de-AT, and de-CH, but you'd still
>> be left inferring that de supported de-DE by default (not necessarily a
>> good assumption, particularly across implementations).
>> es-discuss mailing list
>> es-discuss at mozilla.org
> Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss