this makes more sense than `callee` since `.bind()` functions are slow even in `"use strict"` scenarios.
However, I was not aware about the fact arrow functions have no arguments access at all ... between "cool" and "limiting" if you ask me but if performances are better then it's OK. Also OK would be to have a way to flag a function or a bound one "static" so that no `arguments` or `caller` will ever be available 'cause if this is the performance problem developers would love to have a better way to improve there. In the DOM world, as example, all bound functions accepts one single argument, the event object, while in node.js world basically all emitted functions accept 2 arguments and never/rarely more than two. As somebody said already in another thread, me, as developer, would love to help the JS engine to go faster where needed! Regards On Sat, Jul 13, 2013 at 12:39 PM, Mark S. Miller <[email protected]> wrote: > Arrow functions, whether strict or non-strict, are not supposed to have > their own |arguments| > > > On Sat, Jul 13, 2013 at 11:55 AM, Jeff Walden <[email protected]> wrote: > >> On 07/12/2013 04:59 PM, Andrea Giammarchi wrote: >> > one more thing ... I believe this will impact arrow function too since >> is basically bound callbacks all over the place (or at least this is how I >> believe it will be transpiled) >> >> Sadly, based on the arrow-function patches I've reviewed in SpiderMonkey, >> I don't believe this will be necessarily true. Arrow functions and >> bind-bound functions are two rather different beasts. Bind-bound functions >> are potentially constructible; arrow functions never are. >> |arguments.callee| inside a function that's been bound doesn't refer to >> the bound function -- it refers to the lexical entity. (That is, |function >> f() { return arguments.callee; } f.bind(null)()| is |f|, not |b|.) >> |arguments.callee| inside an arrow function -- at least, so long as arrow >> functions aren't automatically strict, which decision I would revisit -- >> refers to the arrow function. I expect there are other differences I'm not >> yet aware of, that would affect having a common implementation of the two >> concepts. >> >> It seems like a pretty bad idea to me for arrow functions to not be >> substantially semantically similar to bind-bound functions, but they are as >> it stands now. I wish I had the time to sit down and think through a solid >> unification of the two concepts. >> >> Jeff >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
