arrows and a proposed softCall

Angus Croll anguscroll at
Sun Jun 3 11:13:24 PDT 2012

> But that's exactly why we should be conservative about locking users into
>> hard bindings when their intentions are not clear (clear: 'bind' or no
>> |this| value, unclear: arrow functions). As someone who views call/apply as
>> cornerstones of the language and who's libraries depend on it, an
>> unintended hard binding is a needlessly broken utility. But I repeat myself.
> Are you arguing for -> instead of =>, or in addition to =>?

At this point I'd settle for anything that allowed both abbreviated syntax
and late binding via call/apply. That could be any of:

1) Arrow function that shortens syntax but leaves semantics alone
2) Arrow function with soft lexical binding
3) Thin arrow as no-semantic alternative to fat arrow (coffee script style)

Looks like (3) has the most chance of gaining acceptance - that would work
for me.

> There's nothing particularly "unclear" about a function that doesn't use
> |this| or else binds |this|, vs. a function that uses its dynamic |this|.
> Clarity depends on many things including how well documented or commented
> the code -- especially that contract that we just agreed exists -- might be.
> So why are arrow functions "unclear"? Asserting that they are doesn't
> prove the point. It seems to me you're assuming too many developers won't
> learn that => means lexical |this|, and that they'll continue not to learn.

Its impossible for me to prove they are unclear just as its impossible for
you to prove they are clear. I can only:

1) point to the syntax and suggest 'bind' says exactly what it does while
'=>' says nothing about what it does
2) point to unscientific and noisy issue comments at jsfixed and note that
at least some experienced JS devs share my concerns re. lack of clarity

Also note that here, several fine developers got into a mess with figuring
out the impact on 'this' in fat arrows

But I readily admit that I won't know how valid my concerns are until the
syntax starts being used in anger.

> *If the intention is to use call/apply purely as an argument passer this
>> can be indicated by a null context argument which would suppress the error
> This is an incompatible change if done for any function that ignores the
> |thisArg|:
> js> function f() { var self = this; return function () { return;
> } }
> js> var g = f()
> js> var o = {m: f, foo: ""}
> js> var h = o.m();
> js> var foo = "global foo"
> js> g.apply(null)
> "global foo"
> js> h.apply(null)
> ""
> js> g.apply({foo: "new foo"})
> "global foo"
> js> h.apply({foo: "new foo"})
> ""
> Same for ES5 bound functions:
> js> function unb() { return; }
> js> var b = unb.bind({foo: ""})
> js> b.apply(null)
> ""
> js> b.apply({foo: "new foo"})
> ""
> Why should only arrow functions, among all functions that ignore
> |thisArg|, throw when applied with a non-null |thisArg|?
Not suggesting that arrow functions be special cased or that they ignore
|thisArg|. I'm suggesting for all relevant cases (=>, bind and no |this|)
we only throw an error on call/apply if the |thisArg| is non null.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list