what kind of problem is this fat arrow feature trying to solve ?

David Bruant bruant.d at gmail.com
Wed Oct 2 14:54:54 PDT 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131002/6db21d7c/attachment-0001.html>


More information about the es-discuss mailing list