Arrow functions as methods
brendan at mozilla.org
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
> 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 = object.foo;
>>> foo(object, bar);
>> This completely breaks functional abstraction, of course.
>> 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,
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