arrows and a proposed softCall

Yehuda Katz wycats at
Mon Jun 4 15:10:24 PDT 2012

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 {, 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> wrote:

> On Mon, Jun 4, 2012 at 9:54 AM, Brendan Eich <brendan at> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list