On Dec 2, 2011, at 11:56 AM, Nebojša Ćirić wrote: > 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).
Hrm, I missed that. It's not "the JS way". We do not always or even generally endeavor to confine API expressiveness to one paradigm or "way of doing it". It happens that the clunky standard library (ECMA-262 Clause 15) looks OOP-ish, like Java, with methods shared via protoypes, but there are functions too (parseInt is one). That's all old stuff that was done in haste, it shouldn't be taken as restrictive holy writ when considering new APIs. > I think that functional approach could reuse the object-based implementation > with addition of caching to lower the costs. Right! > 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), (1) is all we need in the way of functional (methodical) API, IMHO. If I recall correctly, it includes new methods, not just toLocaleString -- is that correct? /be > 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 <bren...@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. > > /be > > 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 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ć > > > > > -- > Nebojša Ćirić
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
