arrows and a proposed softCall

[Yehuda Katz]

To be honest, I was mostly thinking about this feature from a jQuery
transition perspective.

Right now, callbacks to methods like `each` in jQuery expect to receive a
`this` binding for the current element in the iteration.

For example, in the case of `each`, the call signature looks like this:

jQuery.each(someArray, function(i, item) {
  // this and item are the items in the Array
  // i is the index
});

It's too late for jQuery to fix the order now. However, in the face of
arrows or bound functions, we probably could detect a user intent to use
`this` for their own purposes and use that as a signal to change the order.

jQuery.each = function(array, callback) {
  for (var i=0, l=array.length; i<l; i++) {
    item = array[i];
    if (isBound(callback)) { callback(item, i); }
    else { callback.call(item, i, item); }
  }
};

I don't know whether it makes sense for a brand-new API to be designed this
way, but for APIs that presently make (possibly misguided) use of `this` in
place of a first parameter, the new (user-initiated, not available in ES3)
binding behavior provides a single shot at a better way forward.

Yehuda Katz
(ph) 718.877.1325


On Mon, Jun 4, 2012 at 7:36 PM, Angus Croll <anguscroll at gmail.com> wrote:

>
>
> On Mon, Jun 4, 2012 at 9:54 AM, Brendan Eich <brendan at mozilla.com> wrote:
>
>> You mean you still propose that (=> 42).call({}) should throw, but
>> (function () { return 42; }).call({}) should not?
>>
>> Sorry, this isn't a principled response. There should be no difference in
>> result between those two cases.
>>
>>
> I disagree. You yourself said "so are you looking for an isBound predicate
> just to throw an error? I'm not saying that is a non-goal". The principal
> is let the user know they are trying to set |this| in a hard bound
> function. The level of introspection required to go the extra mile and look
> for |this| usage seems neither desirable or useful. If my function doen't
> reference |this| then I don't care if |this| is modifiable.
>
> However I thought we had some agreement that -> was a valid goal. In which
> case this error throwing stuff is less important (to me at least)
>
>
>
>> Apart from principles, it seems to me you think arrows will be such sweet
>> sugar that people will make mistakes using this-sensitive API contracts,
>> where long-but-this-insensitve-**functions would not be so misused.
>>
>> To demonstrate this we need to see some evidence. It's not enough to
>> worry, or to hypothesize unfixed code shipped and failing at scale due to
>> failure to test arrow function misuse on the part of developers.
>
>
> I'm the first to admit I have no hard evidence, only heresay
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120605/6aa25661/attachment.html>