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 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
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
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
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
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
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
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).
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
9 matches
Mail list logo
