Arrow functions as methods
rfobic at gmail.com
Thu Jul 12 11:41:44 PDT 2012
Thanks Brendan for explaining the problem, I can see how that can get confusing.
> What "it" is a failure?
While fat arrows solve a problem (or rather simplify) with .bind(this) they do introduce a new one. Namely they can't be used as methods. Which would not have being a problem if we had both thin & fat arrows. That basically means that whenever I have to explain someone how to use X I can't tell forget about old functions, I have to teach about one more flavor of it. That's what I see as failure.
> No, not "as methods" as commonly expressed in object literals. Those get
> other shorthand.
They do get other shorthand, but that's makes interoperability between OO & functional only harder, you will have to choose either red or blue pill. While I really wish we could write code in either style and let users decide which style they want to use it.
> People have to say what they mean, they do not get implicit uncurrying
> of |this| as a first parameter.
Yes I do understand this point. My suggestion clearly has issues, but I'm happy to get any other solution that would be issue free and would allow reuse of functions as methods. It could be thin arrow or explicit syntax to expressing desire to get `this` as parameter:
var map = (this, f) => reduce(this, (result, x) => result.concat([ f(x) ]), )
On Wednesday, 2012-07-11 at 23:02 , Brendan Eich wrote:
> Gordon Brander wrote:
> > I noticed an alternative solution to this problem in the ES Wiki:http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax#deferred (see "optional leading `this` initializer"). As I understand it, that would give us some sort of special delimiter for specifying a soft-bound `this` context on a thin-arrow, e.g. in pseudo-code:
> > foo(o | a, b)
> > ...or some-such.
> That syntax was for expressions and definitions of functions, not for
> calls. The idea was to enable parameter default values for |this|. It
> won't do what Irakli wants.
> Soft-bind is not going to fly, see
> https://mail.mozilla.org/pipermail/es-discuss/2012-June/023202.html, and
> Implicitly shifting |this| in call expressions to the front of the
> actual argument list is similarly painful in overhead for implementors,
> besides making the dynamic "two args, or only one?" hazard depending on
> how a callee called from a polymorphic site happened to be expressed.
> What Python does is a bit different:
> Class_of_obj.foo(obj, arg)
> not just
> foo(obj, arg)
> for some identifier-expression 'foo'. But this depends on classes in
> Python, which are not in any way analogous to => function expressions.
> es-discuss mailing list
> es-discuss at mozilla.org (mailto:es-discuss at mozilla.org)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss