Then I guess we need another survey. "What does the JS arrow function proposal mean to you? a) An abbreviated function syntax b) A hard bound lexical |this| binding c) Nothing"
I'd gladly be proved wrong but my guess is most JS developers who don't answer (c) will answer (a). (I see plenty of supporting evidence on Twitter). Thin arrow would be an excellent decoy for those who expect (or want) just (a). This is also in response to Kevin's suggestion that arrow syntax is barely more concise than regular function syntax. I don't think that's the perception in the wider dev community, neither is it mine (in the best case we save four ways - no function keyword, no braces, no argument parens, no return stmt). Personally I expect I can get by using function keyword where using => will break my idioms - but its a bit much to expect everyone to understand and react to these subtleties. I guess I'm trying to anticipate future cowpaths and pave them before they make too much mess. On Sun, Apr 29, 2012 at 11:37 AM, Brendan Eich <[email protected]> wrote: > Brendan Eich wrote: > >> But the lexical part doesn't enter into the contract of the API taking >> the function argument. It's between the API caller and the function >> argument's implementation -- when the latter is a closure in the former, >> lexical |this| often wins. >> > > What does enter into the contract of the API taking the function argument > is whether |this| is dynamically bound and passed with the expectation that > the funarg not use some other |this|. But even then, the funarg is free to > ignore |this|. > > Between lexical-this and no-this, Kevin's analysis shows 80-90% (high end > helped by method definition shorthand) coverage. > > Thinking about arrows as a new thing to teach is fine, but we should not > teach myths. |this| binding in JS today requires careful thought in all the > usual scenarios: constructor, method, callback, global or local function. > You can see why some advocate no-this uber alles! > > But lexical-this is (if memory serves) around 40-50% gross of the 80-90% > Kevin studied. That's big and we know people get that wrong. > > If there's a strong use-case for -> as function shorthand, we should > consider adding -> too. But the use-cases don't look strong enough yet, at > least not to me (and I'm sympathetic!) to go back to TC39 asking for -> on > top of =>. > > /be >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
