ECMAScript collation question
ecmascript at norbertlindenberg.com
Fri Aug 31 15:30:45 PDT 2012
So here's an alternative spec approach:
- Leave the specification of String.prototype.localeCompare as is. That is, if it's not based on Collator, canonical equivalence -> 0 is required.
- For Collator.prototype.compare, require that canonical equivalence -> 0 unless the client explicitly turns off normalization (i.e., normalization is on by default, independent of locale). Support for the normalization property in options and the kk key would become mandatory.
On Aug 31, 2012, at 10:12 , Mark Davis ☕ wrote:
> I think we could go either way. It depends on the usage mode.
> • The case where performance is crucial is where you are comparing gazillions of strings, such as records in a database.
> • If the number of strings to be compared is relatively small, and/or there is enough overhead anyway, the performance win by turning off full normalization would be lost in the noise.
> So if #2 is the expected use case, we could require full normalization.
> — Il meglio è l’inimico del bene —
> On Fri, Aug 31, 2012 at 9:56 AM, Norbert Lindenberg <ecmascript at norbertlindenberg.com> wrote:
> The question for ECMAScript then is whether we should stick with "must do" (the current state of the specifications) or change to "must be able to do".
> The changes for "must be able to do" would be:
> - In the Language specification, remove the description of String.prototype.localeCompare, and require implementations to follow the Internationalization API specification at least for this method, or better provide the complete Internationalization API. That way, localeCompare acquires support for the normalization property in options, and the -kk- key in the Unicode locale extensions.
More information about the es-discuss