function()->{},
Identical in every way to fat-arrow function except not lexically bound,
has access to arguments but not callee/caller, and can be call/applied. No
construct, supports no curlys, implicit return :DOn Sat, Jul 13, 2013 at 9:55 PM, Andrea Giammarchi < [email protected]> wrote: > not a part, I am imaging already a scenario where everyone will start > avoiding `.bind()` in order to use arrow functions because these are faster > ... something like: > > ```javascript > obj.method = function () { > return (e) => { > // rest here > }; > }; > node.addEventListener('evt', obj.method()); > ``` > > ... I don't really like the approach ... can anyone think about a way to > have "arrowified" functions at definition time? Will classes allow arrow > functions magic inline ? nothing to bind anymore in this case ... different > from the JS I know but that might work pretty well for performance ... > although the prototype would be even more messed up ... > > > > > > On Sat, Jul 13, 2013 at 9:47 PM, Andrea Giammarchi < > [email protected]> wrote: > >> 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 > > -- - Matthew Robb
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
