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

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Oct 2 16:14:27 PDT 2013

in line

On Wed, Oct 2, 2013 at 2:54 PM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 02/10/2013 19:45, Andrea Giammarchi a écrit :
>   Yes, only for these particular examples.

Tab mentioned Array extras, that's the reason I've put them in the plate.

Promises ... never used them so far. I'll try to see how convenient is =>
there the day I'll need/use them.

>   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!

Still that does not promote reusable code but inline ad-hoc operation
usually abused in for loops too as it is the classic `$('CSS')` anti
pattern repeated all over in jQuery world. It took a while to tell
developers that maybe they simply need to address that once per
closure/logic ^_^

You know what I mean ... glad to know SpiderMonkey can optimize that. I
hope V8, JSC, and Chakra can do the same as transparent win for laziest

> Why would they have even tried interoperability with DOM events?

you know the myth "write once, deploy everywhere" right ? They decided to
avoid the single Event object as arguments with its types. There's no way
in common Emitters to have an event object and an event type ... only a
hopefully null error and some result after or forced different behavior
through manual `emit` when you end up passing by default `null` as first
emitted argument due common handler pattern.

Also node didn't know about handleEvent ... so yes, it would have been a
better world if node.js chaps had a better look in what DOM Events were
offering when they started the implementation, **IMO**

> All in all, I think that what you're trying to demonstrate

I am not trying to demonstrate anything ... I am showing solution to common
problems trying to understand where this => would be better than what we
have now.

I haven't said fat arrow is bad, I am trying to understand why is better
... I don't have to use it and I won't for a while since I am still a
old-school hand written optimized JS donkey-idiotic developer but since it
has been discussed and applauded for long time now I am curious why is that
and discovered a lot in this thread.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131002/ecec57a5/attachment.html>

More information about the es-discuss mailing list