<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 20, 2011, at 4:56 PM, Axel Rauschmayer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">I meant: One can already write methods (functions with dynamic |this|) in a very concise manner, thanks for Allenís object literal extensions. Then you have to ask: Do we really need the dynamic this arrow ->, or can we make do with just the lexical this arrow =>.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We do not propose to cripple the shorter syntax. The dynamic-this use-cases for functions are at least as common as "var self=this;... function(){... self...}" use-cases for lexical this, or roughly about the same (in my experience -- anyone have data?).<br></blockquote><br><br>Are functions that depend on dynamic |this| ever *not* methods?</div></blockquote><div><br></div>Sure. The main use-case is constructors (and you can make a function do double-duty, as a constructor or a function called without 'new').</div><div><br></div><div>Also, some times, people write functions not used as methods but called via .call or .apply. It happens.</div><div><br></div><div>On the other side of the fence, it's not uncommon to have "methods" that want lexical or no |this|. In the closure pattern, you often see code like so:</div><div><br></div><div><font class="Apple-style-span" face="Courier">  function Car(make, model, key) {</font></div><div><font class="Apple-style-span" face="Courier">    function validate(key) {...}</font></div><div><font class="Apple-style-span" face="Courier">    function cancelAlarm() {...}</font></div><div><font class="Apple-style-span" face="Courier">    return {</font></div><div><font class="Apple-style-span" face="Courier">      start: function (key) {</font></div><div><font class="Apple-style-span" face="Courier">        if (validate(key)) {</font></div><div><font class="Apple-style-span" face="Courier">          cancelAlarm();</font></div><div><font class="Apple-style-span" face="Courier">          ...</font></div><div><font class="Apple-style-span" face="Courier">        }</font></div><div><font class="Apple-style-span" face="Courier">      },</font></div><div><font class="Apple-style-span" face="Courier">      lock: function ...,</font></div><div><font class="Apple-style-span" face="Courier">      unlock: function ...,</font></div><div><span class="Apple-style-span" style="font-family: Courier; ">      // etc.</span></div><div><span class="Apple-style-span" style="font-family: Courier; ">    };</span></div><div><font class="Apple-style-span" face="Courier">  }</font></div><div><br></div><div>The methods of the object literal do not use |this|, but if they did, they might prefer to use => and avoid the hazard of an accidental |this| reference within one of their bodies being re-bindable.</div><div><br></div><div><br><blockquote type="cite"><div>Wouldnít you always want to use an object literal for methods, especially if some features (such as |super|) depend on it?<br></div></blockquote><div><br></div>Probably. But so what?</div><div><br></div><div>We're not making mandatory syntax either way with function, so why should we with arrow?</div><div><br></div><div><br><blockquote type="cite"><div>Isnít it then a case of<br>        { foo: (x) -> { ... } }<br></div></blockquote><div><br></div>You mean => here, I think.</div><div><br></div><div><br><blockquote type="cite"><div>versus<br>        { foo(x) { ... } }<br></div></blockquote><div><br></div>Arrows are not in yet. The method syntax looks like it is the most agreed-to among the <a href="http://wiki.ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions">http://wiki.ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions</a> at this point.</div><div><br></div><div>BTW, if Arrows make it then, as with binding forms such as const and let, the property assignment shorthand will be</div><div><br></div><div>    { foo(x) => ... } // or =>, and with ... an expression or block</div><div><br></div><div><br><blockquote type="cite"><div>Maybe I just like the distinction introduced by block lambdas too much:<br>- dynamic this --> existing functions and methods<br>- lexical this --> new, more compact construct, mainly used as the argument of functions and methods.<br></div></blockquote><div><br></div>Block-lambdas are not arrows. Arrows are just syntax and try to shorten function usage in general (including the .bind or var self=this; idiom). Block-lambdas must preserve Tennent's Correspondence Principle, so they have no choice but to treat |this| lexically.</div><div><br></div><div><br><blockquote type="cite"><div>This distinction works well as a rule of thumb and keeps things easy to explain.<br></div></blockquote></div><br><div>It's not that simple: existing functions can and do use various binding hacks to make |this| or a substitute "lexical". Anyway, functions have |this| parameters, whether created by old function or new arrow syntax.</div><div><br></div><div>/be</div></body></html>