block-lambda revival

Irakli Gozalishvili rfobic at gmail.com
Fri Jun 24 01:35:49 PDT 2011


My 2 cents here.

Some people today refuse use of `this` entirely to avoid this type of bugs. To do so they start each method with:

var self = this;

Now with arrow functions this pattern can become even easier. Just use fat arrows => everywhere with in a method body, problem solved.

In addition lints 
> 
> 
> On Thu, Jun 23, 2011 at 10:00 PM, Brendan Eich <brendan at mozilla.com (mailto:brendan at mozilla.com)> wrote:
> > On Jun 23, 2011, at 9:49 PM, Mark S. Miller wrote:
> > 
> > > Presently in JS, when seeing a "this", to understand what it means, the eye needs to scan backwards for the closest enclosing occurrence of "function" as a keyword. As this example shows, even this is accident prone. If we introduce multiple special forms that can introduce a this-rebinding boundary, where the new ones are easily missed, we make this burden worse. Is "->" easily missed? (I would guess so.) And if it is, what are we getting in exchange, and is it worth it?
> > 
> > That's a good point if the special forms are not "just syntax" (including some .bind or var self = this rewriting). Arrows at least do not add semantically to the function-like menagerie, so the problem is not different in kind from the one that bit the 'function'-based code you showed. But block lambdas do not have the hazard at all.
> > 
> >  If you take your argument to the limit, it wants to kill 'this' (something I believe you wouldn't mind ;-). This could be just another reason to prefer block lambda revival to arrow function syntax.
> > 
> >  However, I recall from the last TC39 meeting that some folks on the committee seemed outraged that block lambda revival (because of TCP conformance -- no way around this) lexically binds 'this', always. I believe the problem they had was that they believed shorter function syntax should be neutral on 'this' binding, to make functions in all their current use-cases more convenient.
> > 
> >  This is a difference in risk evaluation or tolerance, perhaps. We should try to get to the bottom of it.
> 
> I missed the risk issue until today. I suspect others have as well.
> 
> Until I started thinking about the implications of Tom's bug[1], I was also enthusiastic for shorter function syntax. Yes, I have always been even more enthusiastic about TCP-respecting lambdas, but put that aside for the moment. Assuming I couldn't have those or any other semantic improvement (const functions, etc), until today, my dominant reaction to JS functions has always been "But they're so darn verbose! Can I please have a shorter way to say these? Please?". Be careful what you wish for ;). 
> 
> The verbosity is a genuine cost. However, I didn't realize the hidden cost I was unknowingly willing to pay in exchange. If the tradeoff is against making it harder to spot errors when reading code, then I'd prefer to pay the current "function" verbosity cost. If you offered me "=>" in exchange for also accepting "->", I may have agreed yesterday. Today, not. 
> 
> 
> [1] And that Tom made it. And that we all missed it for over 10 months.
> -- 
>  Cheers,
>  --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org (mailto:es-discuss at mozilla.org)
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110624/f70ae6c3/attachment.html>


More information about the es-discuss mailing list