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 discussion.
Cases: 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). Benchmark: http://i18n.kaziprst.org/test-driver.html Code (formatter is intentionally trivial in both cases): http://i18n.kaziprst.org/funct-impl.js http://i18n.kaziprst.org/object-impl.js 01. децембар 2011. 11.53, Brendan Eich <bren...@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 > works. > > /be > > > 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). > > > -Shawn > > > > http://blogs.msdn.com/shawnste > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Nebojša Ćirić
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
