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
devs.




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

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