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
