Le 02/10/2013 19:45, Andrea Giammarchi a écrit :
so fat arrow does not solve much here, I can use self as first
argument and I am good.
`forEach` and all other arrays accept a second argument
`array.forEach(doStuff, boundContextObject);`
so fat arrow does not solve a thing in mostly all Array extras.
Both examples are most certainly design mistakes. It feels absurd
that every function accepting a function as argument must also
have a second argument for the |this| value (or even variable
number of arguments to be passed around). Especially in the ES5
era with Function.prototype.bind.
I wasn't talking about how great this approach is, I was rather saying
that it is possible to send a context
Yes, only for these particular examples. But that's where it stops,
arrow functions can be used as Node callbacks for instance. In promise's
.then, you can pass a function or two, but not their |this|. Which
|this| is used then? If you want the lexical |this|, arrow functions work.
so design mistake or not, the fat arrow won't solve anything if not
extra operations/oibjects to create promoting a "reuse nothing"
pattern hopefully optimized better than current inline function, but
something I've personally never advocated if operations are repeated.
I create the `forEach` utility unscoped as much as possible and once
per execution lifecycle, so that I can send the context through the
second argument instead of create O(n) times the inline function or
the fat arrow.
Optimization is possible to avoid creating n function objects.
Actually, I've discussed that with Jim Blandy (who works on
SpiderMonkey) some time ago and he told me that if given some heuristics
on function length and number of repetition, it's completely inlined and
the function is only actually allocated in the slow path (so
asymptotically never). It also works with nested .forEach!
The design mistake is emphasized by the inconsistency in the order
of arguments in the 2 examples you provide.
I'm glad Node.js didn't make all async functions accept another
argument for |this|.
for **DOM** I use handlers as specified by **W3C**
Since when the DOM is specified by W3C? Must be about 10 years it
isn't the case anymore</troll> ;-)
Passing a function directly is standard too.
Thanks for the enlightening troll, I was talking about a technique
developers keep forgetting and ignoring, a technique described here
which is **not a trick** just **standard behavior**
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener
I know, I'm aware of it. I was just saying that passing just a function
is standard too. Each approach has benefits and downsides. Arrow
functions benefit one pattern. It doesn't mean unbalance the other
pattern, you can still use it.
But "won't be able to remove later on" is false:
document.addEventListener('DOMContentLoaded', function dcl(){
// whatev's
document.removeEventListener('DOMContentLoaded', dcl);
});
You didn't use a fat arrow because indeed you cannot use one unless
named and its name is available so ... what is your point here?
yeah, sorry about that, you're right. I actually hit that problem in a
TypeScript project. In a few instances, I needed to remove a listener
and inline arrow functions don't work for that.
The conclusion I made was that it was rare enough to remove a listener
this way that I could just get back to an inline non-arrow named
function. Since I use direct functions and not handler objects, I never
use |this| anyway (which is the target or currentTarget, I never
remember), so arrow functions are just a shorter convenience.
But that's just my opinion.
I understand that in some cases, specs allow to pass |this| or
additional arguments, but it doesn't make it a good idea. I see
the fact that Node.js didn't take that road as a very strong signal.
David
node.js has been lucky enough to born in an era where
`Function.prototype.bind()` was already there otherwise would have
came up with a similar solution.
That said, node.js also broke completely interoperability with any DOM
Event we know since 1999 thanks to the (in?)famouse double argument
pattern with the nullish error as first argument.
Why would they have even tried interoperability with DOM events? On the
server, you don't need DOM events, do you? DOM implementations, if they
do implement events will be interoperable, but Node.js doesn't. More,
Node.js has its own event system which doesn't have the 2 arguments
convention.
All in all, I think that what you're trying to demonstrate is that there
are coding styles in which arrow functions aren't necessary. I agree.
Arrow functions are a convenience (No! Brendan! Put that hammer down!!),
it's possible to live without them. But there are some coding styles
that benefit from them.
I've used them extensively in a project (with TypeScript). It took me
some time to adjust, but overall, the code feels lighter and more
readable to me (and no coworker I worked with complained, some started
to like it better in some circumstances). They avoided the issue of
forgetting "var self = this;" which people who aren't experts in the
language easily forget and are annoying to track down because only
noticeable at runtime. They were worth it in my experience.
Note that it's not because they're in the language that you have to use
them. But someone else explained that better that I would:
http://www.youtube.com/watch?v=N2u44-zZYdo&list=PL37ZVnwpeshF7AHpbZt33aW0brYJyNftx
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
