Re: Globalization API Feedback - moar!
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
New Globalization API draft posted to wiki
The December 1, 2011 draft is available at http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts This draft adds re-specifications of locale sensitive methods in the ECMAScript Language Specification (localeCompare, toLocaleString, etc.), adds implementation dependent best fit algorithms for locale and date-time format matching, removes ValueError, and clarifies algorithms and prose in numerous places. The draft reflects roughly the state of discussions after the meeting of the Globalization ad-hoc on November 15, before the TC39 meeting the following day. Changes resulting from feedback from TC39 and on es-discuss@ will be incorporated later. Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API Feedback - moar!
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ć ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API Feedback - moar!
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 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
Re: Globalization API Feedback - moar!
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
Re: Globalization API Feedback - moar!
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? Norbert's list ( http://wiki.ecmascript.org/doku.php?id=strawman:globalization-integration) contains only what's currently available in ES. It is possible that in some future iteration of both standards we may have to add new built in methods (say to handle time zones, calendars, break iterators...) - but that's out of scope for the current spec. We would need to flesh out actual mechanizm of combining (1) and (3) - importing, what to do if i18n support is not available... I am leaning towars having (1) and (3) available, skipping (2) completely. We can't remove (1) from the language so we better improve it. The question is - should we use (2) or (3) to achieve that. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Globalization API - Sample Use Cases
Instead of continuing with the previous thread, I figured it would be easier to start a new one. One of my main points about the current Globalization API is that the API seems to be designed around complex use cases vs. simple use cases. Whether intentional or unintentional the Globalization API fills two gaps in ECMAScript: number formatting and date formatting. Setting aside the ability to internationalize currencies and dates, this is a capability that has long been missing from ECMAScript and developers will rejoice if/when it arrives. That being said, I think there's a strong possibility that simple date/number formatting will end up being a popular use case of the API as opposed to those who are actively looking for locale-specific changes due to an internationalized product. I'd venture a guess to say that the common uses would end up being: 1. Date formatting 2. Number formatting 3. Comparing/sorting (with the current Collator) I would love it if the ability to format numbers and dates were simpler than currently spec'ed, more specifically, if the object literals could be done away with in favor of formatting strings. Yes, I know formatting strings have some limitations, however the way I have created internationalized applications in the past has been by abstracting out the internationalized parts into configuration files (such as a Java properties file). The data from that could then be passed into a JS API that Did The Right Thing. Formatting strings make this trivial, needing to code up an object literal makes this trickier (JSON is not a great format for config files). Just a few extra cents. -N ___ Nicholas C. Zakas http://www.nczonline.net ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API - Sample Use Cases
I agree that object literals are more verbose, but they are also more readable. I did hear some complains about formatting strings missing from the latest spec (we had them before), and mostly from people that know how to use them (I still need to look up CLDR docs to write a semi complex one). The easy solution to that is to add 2 more fields to the options (or have them as separate parameter): 1. pattern - as is, I know what I want - MM/yy always generates 9/74 no matter the locale. 2. skeleton - MM/yy will get you closest matching pattern for a given locale. If pattern or skeleton fields are specified, we ignore the rest of the options object. We had this approach before and removed it from the spec to simplify the API, but it shouldn't be hard to get it back in. 02. децембар 2011. 13.28, Nicholas C. Zakas standa...@nczconsulting.comје написао/ла: Instead of continuing with the previous thread, I figured it would be easier to start a new one. One of my main points about the current Globalization API is that the API seems to be designed around complex use cases vs. simple use cases. Whether intentional or unintentional the Globalization API fills two gaps in ECMAScript: number formatting and date formatting. Setting aside the ability to internationalize currencies and dates, this is a capability that has long been missing from ECMAScript and developers will rejoice if/when it arrives. That being said, I think there's a strong possibility that simple date/number formatting will end up being a popular use case of the API as opposed to those who are actively looking for locale-specific changes due to an internationalized product. I'd venture a guess to say that the common uses would end up being: 1. Date formatting 2. Number formatting 3. Comparing/sorting (with the current Collator) I would love it if the ability to format numbers and dates were simpler than currently spec'ed, more specifically, if the object literals could be done away with in favor of formatting strings. Yes, I know formatting strings have some limitations, however the way I have created internationalized applications in the past has been by abstracting out the internationalized parts into configuration files (such as a Java properties file). The data from that could then be passed into a JS API that Did The Right Thing. Formatting strings make this trivial, needing to code up an object literal makes this trickier (JSON is not a great format for config files). Just a few extra cents. -N ___ Nicholas C. Zakas http://www.nczonline.net __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
What prevents built-in constructors from being extended?
I’m still trying to understand why some of the built-in constructors can’t be extended. The following describes my current understanding. If you would, please let me know where/if I’m wrong. - The following built-in constructors can’t be easily extended: Array Boolean Date Function Number Object RegExp String Error and sub-constructors - Reason (Array): Array instances need special support to update the length property depending on what elements are added. But that specialness should go away with Allen’s proposal for overriding element access via []. - Reason (all): The constructors can’t be invoked as functions while handing in `this` – be it that they create new instances, be it that they do something else – they can’t be made to add properties to an existing instance. This prevents the pattern SuperConstructor.call(this, arg1, arg2, ...) from working. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
