Arrow functions as methods

Brendan Eich brendan at
Wed Jul 11 14:58:21 PDT 2012

Irakli Gozalishvili wrote:
>> We've been around that block and will go again. If we want convenient
>> unbound-this function syntax, -> stands ready. I proposed it along with
>> => originally but it was cut by TC39 during our March meeting in order
>> to achieve consensus on =>.
> Yeah I'm aware of that, but problem as I see is that new fat arrow 
> functions can not fully replace existing functions.

That is not a problem, or rather: not a problem with fat arrows.

> In combination with thin arrows they would but since they have being 
> cut ended up with a dependency on an old style function in order to 
> wrap arrows to make them usable as methods. I consider it's a failure.

What "it" is a failure?

Saying you can't get lunch too when you get a good free breakfast and 
therefore breakfast was a failure is just wrong. We got short function 
syntax for by far the most common forms: methods in object literals, and 
(with =>) functions that bind outer |this| or do not use |this| at all. 
That's winning, it is not a failure.

>  People deal with this pretty well in practice, usually by writing
>> small-world codebases and wrapping anything unknown that needs
>> contract-enforcement along these lines.
> Well but as pointed out above you need an old style functions to make 
> arrows usable as methods,

No, not "as methods" as commonly expressed in object literals. Those get 
other shorthand.

> I think such dependency is very unfortunate.

You're using a particular functional pattern, it's neither that common a 
case nor the end of the world to use long-hand function.

Yes, -> would help. That's the thing to write, not "[=> is] a failure".

>>> Passing owner `object` of the arrow method as first argument solves
>>> this problem, by making
>>> just a sugar for
>>> var foo =;
>>> foo(object, bar);
>> This completely breaks functional abstraction, of course.
>> f(a)
>> and
>> o.m(a)
>> in JS should never pass more than one actual parameter to the callee,
>> however it was declared or expressed.
> Unfortunately I still do not understand why is that a problem,

Why what is a problem? Splitting call expression evaluation semantincs 
at runtime based on how the callee was expressed?

> specially since Claus's wrapper can be used to achieve that.

People have to say what they mean, they do not get implicit uncurrying 
of |this| as a first parameter.

> It's just I think it makes it a much better default.

Default for what? Only for => functions at runtime? That is,



o.m(o, a)

if and only if o.m references a function expressed by => syntax, and 



If I write a method that doesn't need |this| or uses outer |this|, and 
use an arrow, I get an extra argument at the front, but if I use a 
function, I don't. That is going to generate bugs.

You're focusing too much on the case where the callee uses dynamic 
|this| or wants to. Such a callee can't use => syntax.

The programmer must write the function according to the API contract. 
For dynamic |this| contracts, use a long-form function or keep up the 
arguments and pressure for supporting -> as well. Blaming => for not 
serving this use-case is not going to help.


More information about the es-discuss mailing list