Bound instance-function vending (was RE: Arrow binding)

Brendan Eich brendan at
Sun Apr 29 13:51:15 PDT 2012

Angus Croll wrote:
> Then I guess we need another survey.

What was the first survey?

Kevin's analysis was on code, using a tool to classify functions as 
no-this/lexical-this vs. the rest.

> "What does the JS arrow function proposal mean to you?
> a) An abbreviated function syntax
> b) A hard bound lexical |this| binding
> c) Nothing"

This is all subjective and (without implementations to user-test) 
prospective. A survey is not going to be helpful IMHO. Rorschach test...

> I'd gladly be proved wrong but my guess is most JS developers who 
> don't answer (c) will answer (a). (I see plenty of supporting evidence 
> on Twitter). Thin arrow would be an excellent decoy for those who 
> expect (or want) just (a).

What do you mean by "decoy"?

This is all kind of twitter-ific, and so pretty much useless.

> This is also in response to Kevin's suggestion that arrow syntaxis 
> barely more concise than regular function syntax. I don't think that's 
> the perception in the wider dev community, neither is it mine (in the 
> best case we save four ways - no function keyword, no braces, no 
> argument parens, no return stmt).
You mean where Kevin wrote:

     // On what basis is this:
     this.initialize = () -> { ... };

     // any better than this?
     this.initialize = function() { ... };

There are a couple of characters saved, but it's less readable.  Why 
introduce new syntax for such dubious gain?

with a space before the -> and one before { in both alternatives, and 
with the parameter list costing the same no matter what, there are five 
characters saved (' ->' vs. 'function').

Five is good, I like it (I like thin arrows and proposed them along with 
fat arrows initially). But if this use-case is rare enough due to => and 
method definition shorthand (combined with Object.extend or better where 
possible), it may not be worth the added cost of ->.

What's the cost of adding ->? Mainly users having to remember when to 
use which, and getting it wrong. That's not a trivial concern, and it 
kept -> out of consensus at the last TC39 meeting.

> Personally I expect I can get by using function keyword where using => 
> will break my idioms - but its a bit much to expect everyone to 
> understand and react to these subtleties. I guess I'm trying to 
> anticipate future cowpaths and pave them before they make too much mess.

Doing nothing leaves the cows falling off the wrong-this cliff. Doing 
something means adding syntax, there's no way to make a breaking change. 
Adding two things instead of one makes not only two things, but the 
problem of choice.

We may get -> yet, don't get me wrong. But it won't come from surveys or 
twitter samples.


More information about the es-discuss mailing list