I18n - defining format() and compare() as getters to simplify usage

[Norbert Lindenberg]

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ć