I can imagine doing this for Collator.prototype.compare because
Array.prototype.sort is such a common use case for it, but why for the format()
methods? We don't want to impose the overhead of creating a bound function on
each call to format() unless there's a good reason...
Of course, doing it for one and not the other is somewhat inconsistent. And
since ES 5 has Function.prototype.bind (implemented in the leading browsers
except Safari), it's not hard to bind compare() without library support:
myArray.sort(collator.compare.bind(collator));
Norbert
On Jan 31, 2012, at 10:04 , Nebojša Ćirić wrote:
> We (i18n group) mentioned slight problem with Collator.compare() method to
> Allen at the last i18n meeting.
>
> The problem is that you can't do:
>
> var col = new Intl.Collator(...);
> array.sort(col.compare);
>
> because of the binding loss.
>
> Allen proposed something like this as a possible solution (typing from
> memory):
>
> Collator.prototype = {
> get compare(a, b) {
> var that = this;
> return function(a, b) { uses that; return a < b };
> }
> }
>
> It seems that all major JS libraries*, except jQuery, try to help user not to
> stumble on this problem. Should we include this into spec?
>
> I think that if we do it for compare() method, we should then do it for
> format() methods too, since that would allow user to pass functions around
> instead of objects.
>
> This should not apply to supportedLocalesOf functions.
>
> What do you think?
>
> * http://www.alistapart.com/articles/getoutbindingsituations/ (see
> "JavaScript frameworks do it" section)
>
> --
> Nebojša Ćirić
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
