<div dir="ltr">in line<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 2:54 PM, David Bruant <span dir="ltr"><<a href="mailto:bruant.d@gmail.com" target="_blank">bruant.d@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Le 02/10/2013 19:45, Andrea Giammarchi
      a écrit :</div><div class="im">
    <blockquote type="cite">
      <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br>
          </div>
        </div>
      </div>
    </blockquote></div>
    Yes, only for these particular examples. </div></blockquote><div><br></div><div>Tab mentioned Array extras, that's the reason I've put them in the plate.</div><div><br></div><div>Promises ... never used them so far. I'll try to see how convenient is => there the day I'll need/use them.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">
          </div>
        </div>
      </div>
    </blockquote></div>
    Optimization is possible to avoid creating n function objects.<br>
    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!</div></blockquote><div><br></div><div>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 ^_^</div>
<div><br></div><div>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.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im"><span style="color:rgb(34,34,34)">Why would they have even tried interoperability with DOM events? </span></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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**</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><br>
    All in all, I think that what you're trying to demonstrate</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks</div><div><br></div><div><br></div></div></div></div>