Mark many framewors/libraries/younameit attach listeners at construction time, there is where everyone feels like it's cool and fast and better, and shorter to use arrow functions, then they have to mix between removable listeners and not.
I personally pass objects as listeners, providing an `handleMethod` so that I never need to address functions or methods to be able to remove a listener via an event, unfortunately when nodejs was born developers didn't know this way of adding listeners so that's not even an option in node. Having arrows functions with all these "refactoring caveats" doesn't feel smart because you always want to be able to re-schedule a setTimeout, you always want to be able to have a recursion without trusting the context that could be just undefined (or the global one if transpiled in older engines) and you always want to be eventually able to drop a listener in certain circumstances ... or at least, that's the reason I still try to avoid using arrows functions. For "greppability sake", code consistency and reliability, a callee like feature would be a good solution for all cases. We had this before, and it was useful. It got lost together with other things that were not as useful and secure at the same time. Then if it's just me, feel free to ignore my thoughts on callee. Best Regards On Fri, Feb 27, 2015 at 4:34 PM, Mark Miller <[email protected]> wrote: > Why do arrow functions need to reflect on themselves? I think it is more > useful for all code "directly" inside a non-arrow function to be able to > reflect on that non-arrow function. If I wrote an arrow function and then > found I wanted it to reflect on itself, I'd be happier rewriting it as a > non-arrow function than I would with either > * the complexity of a whole new set of special forms for arrow functions > to reflect on themselves, or > * (as in the original proposal) making it more difficult for code in an > arrow function to reflect on their containing non-arrow function. > > > > On Fri, Feb 27, 2015 at 8:00 AM, Rick Waldron <[email protected]> > wrote: > >> >> >> On Thu Feb 26 2015 at 8:22:55 PM Claude Pache <[email protected]> >> wrote: >> >>> >>> > Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock <[email protected]> a >>> écrit : >>> > >>> > >>> > On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote: >>> >> For most of these, my first reaction is meh. They all make sense and >>> violate no principle, but are they worth it? >>> >> >>> >> I do not like the arrow function behavior. For anything named >>> function.something occurring within an arrow function, I'd expect it to be >>> about the lexically enclosing non-arrow function. I do not object to the >>> idea that there be such a special form that is about the arrow function, >>> but it needs to be spelled differently. I have no concrete suggestion >>> though. >>> > >>> > We have to work with the reserved words we have available, there >>> really need to apply equivalently to all functions, arrow or otherwise >>> defined. The only other available keyword that seems at all suggest of >>> these use cases is 'in' >>> > >>> > in.callee (or whatever) >>> > in.count. >>> > in.arguments >>> > >>> > If we went that route I'd probably still stick with 'function.next' >>> for that use case >>> > >>> > Allen >>> >>> That one has just popped in my mind :-) >>> >>> =>.arguments >>> >>> >> I was thinking exactly this while I was reading Allen's post. >> >> Would class method definitions use `class.*`? Seems like the wrong >> abstraction..? Maybe all functions and method definitions use `function`, >> while arrows use `=>` (or whatever) to preserve correspondence to >> possible outer function? >> >> Rick >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Text by me above is hereby placed in the public domain > > Cheers, > --MarkM > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
