I'm sorry that I could not reply to the multiple replies I got last weekend. Simply can't get the time - plus I have a phobia of fan-out replies (an issue with mail-based discussion groups?)
In any case here's a potted reply that addresses at least some of the points: 1) Kevin et al suggested YAGN call/apply on (non-method) functions. Here's a pretty neat example where call/apply is a perfect fit for standalone functions - and would break if replaced with fat arrows. https://gist.github.com/2520731 It's a simplified version of a a localStorage function (itself a mixin BTW) which defines standard encoding methods and then mixes in whatever storage technique is available to the browser. (An added bonus of having functions here, aside from privacy, is that we can employ hoisting to move the implementation nitty-gritty to the bottom, so as not to obscure the core process) 2) Brendan et al pointed out that we already have hard |this| binding in the form of Function::bind. Yes, but bind is so blatantly explicit in its intention, the probability of surprise is almost certainly less than with arrow functions, whose hard lexical binding will surely come as a surprising side effect to many. 3) Several people suggested that there is a strong desire for a more intuitive form of |this| binding. Yes, people get confused by this binding; even though it is not hard to learn the rules, and I know them very well, I still trip over them sometimes. But unless we are going to introduce a "hella strict" mode that reverts all previous rules of |this| binding, yet another rule will just add to the morass. Most of the "yay, fat arrow" comments I've seen from the dev community are celebrating its brevity, I expect many of the authors have zero knowledge of the lexical binding implications (why would they, unless they came from CoffeeScript?). Now matter how much we justify fat arrow behavior as part of a long term vision, to many it is going to be a hidden, and unwanted side effect. At least introduce thin arrow at the same time, as a carrot to lure who just want (and just expect) an abbreviated function syntax. On Mon, Apr 23, 2012 at 3:01 PM, Brendan Eich <bren...@mozilla.org> wrote: > Brendan Eich wrote: > >> No, in any such prototype-getter-makes-bound-**function scenario, we >> would need memoization, so that >> >> o.m === o.m >> >> (Edit: I see you mention this below.) >> > > The real problem is better captured by showing the prototype p and two > instances, o and q: > > p.m === p.m > > should be true. So should > > o.m === o.m > > and > > q.m === q.m > > but what about > > o.m === p.m > > and > > o.m === q.m > > JS requires distinct bound function identity from the unbound p.m > identity, so false and false. > > If we managed to extend JS with a classy declarative syntax that enabled > vtables, while keeping functions first class (at the price of > prototype-chain mutation: assignment to override, or shadow; also of course > delete), then we might well want true and true. But there would be no way > in JS itself to implement such magic in terms of properties (data or > accessor, doesn't matter) with function values. > > This is why I continue to think that we won't see what Alex predicted: > prototype getter method vending. We haven't see it much in the wild yet > either. > > /be > > ______________________________**_________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
