<div dir="ltr">It's a knockout choice I would say, nothing to do with the fact you cannot have an `handleEvent` in there.<div><br></div><div>Look at [eddy.js](<a href="https://github.com/WebReflection/eddy#event-driven-js">https://github.com/WebReflection/eddy#event-driven-js</a>) or put in in your project and you could handleEvent all the things, DOM and not ^_^</div>
<div><br></div><div>As easy as that, but you confirmed developers are not familiar at all with such pattern: this is bad, IMO, bad for them as massive limit over architectures aimed to deal with the DOM and/or even server side JS.</div>
<div><br></div><div>That being said, I understand your very specific knockout base, but that's a surrounding env problem that didn't give you an easy way to solve this if not through bind or `self` addressed variable :-(</div>
<div><br></div><div>Thanks for sharing though, libraries/frameworks are always a good example of "already got this problem in here".</div><div><br></div><div>br</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Oct 2, 2013 at 2:55 PM, Marius Gundersen <span dir="ltr"><<a href="mailto:gundersen@gmail.com" target="_blank">gundersen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Look at knockout.js and the way computed properties work. You quickly end up with multiple bound functions on a single object, which are always anonymous. The projects I've worked on lately has a lot of `var self = this` to get things to work. Because we use knockout.js we don't have any native dom event handlers, so your trick with the eventHandler method won't work. And we use pubsub, which affect observables on the `this` object, and Ajax is handled through Promises, which also needs access to the `this` object. </p>
<span class="HOEnZb"><font color="#888888">

<p dir="ltr">Marius Gundersen </p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Oct 2, 2013 11:35 PM, "Andrea Giammarchi" <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">when do you need to address at runtime so many methods per instance/object ?<div><br></div><div>I've got the "solve inline" thing but I keep wondering when, where, and why, we need so many inline runtime bound method attachments.</div>


<div><br></div><div>Any real code example beside showing how shorter it is ?</div><div><br></div><div>Promises could simply implement handleEvent too though, it will make objects reusable per each promise lifecycle at any time and with hot-swap per each handleMethod possibility.</div>


<div><br></div><div>Very powerful, too bad developers behind didn't propose this approach too (yes, handleEvent can be swapped at runtime, that's how you could create a whole new world of possibilities through a single object and without even bother the DOM through add/remove listeners)</div>


<div><br></div><div>Thanks</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 2:23 PM, Marius Gundersen <span dir="ltr"><<a href="mailto:gundersen@gmail.com" target="_blank">gundersen@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 dir="ltr"><div><div><div><br>Every time someone wants to make a framework in JS they need to consider `this`. For example, a simple pubsu library could look like this:<br>


<br></div>publish("event", arg1, arg2)<br>

</div>subscribe("event", function(arg1, arg2){<br></div>  //do something, e.g. this.something = arg1+arg2<br><div>}, this);<br></div><div><br></div><div>But now the callback has the wrong this. One way around this is to force people to use bind(this), or you can force developers to always support a boundContext argument for every callback. For example, in promises:<br>




<br></div><div>doSomething().then(function(result){<br></div><div>  this.result = result<br></div><div>}, this);<br><br></div><div>Or with Knockout:<br><br></div><div>this.sum = ko.computed(function(){<br></div><div>  return this.a() + this.b();<br>




</div><div>}, this);<br><br></div><div>Or with array functions:<br><br></div><div>this.array.filter(function(a){<br></div><div>  return a>5;<br></div><div>}).forEach(function(a){<br></div><div>  this.sum += a;<br></div>




<div>}, this);<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">These can all be simplified using the fat arrow:<br><br></div><div class="gmail_extra">subscribe((arg1, arg2) => this.something = arg1 + arg2);<br>




<br></div><div class="gmail_extra">doSomething().then((result) => this.result = result);<br><br></div><div class="gmail_extra">this.sum = ko.computed(() => this.a() + this.b());<br><br></div><div class="gmail_extra">




this.array.filter((a) => a>5).forEach((a) => this.sum += a);<br><br></div><div class="gmail_extra">Not only does it reduce the amount of typing, which makes it easy to fit all these examples into a single line, it takes care of the this variable, which is used in a lot more places than DOM event handlers.<span><font color="#888888"><br>




<br></font></span></div><span><font color="#888888"><div class="gmail_extra">Marius Gundersen<br></div></font></span><div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">
On Wed, Oct 2, 2013 at 8:14 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@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 dir="ltr">If you cannot use fat arrow to define prototypes than you cannot recycle functions per each instance neither.<div>




IIRC you are behind a pretty damn good framework that works on DOM and indeed I was wondering if `handleEvent` would have been your choice there too.</div>
<div><br></div><div>Thanks for your thoughts.</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 11:05 AM, Benoit Marchant <span dir="ltr"><<a href="mailto:marchant@mac.com" target="_blank">marchant@mac.com</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>One could say that JavaScript is an object oriented language where functions are first class citizen. But JavaScript doesn't have <b>methods, </b>which in most oo languages have the feature of always running with this being the object the methods is executed on. </div>





<div><br></div><div>Was introducing a new type "method" considered? In JavaScript it would solve one class of problem we have with functions, which is the one I've been most impacted with as I generally use JS in an more oo way than functional way. And yes, I used more handleEvent for that reason.</div>





<span><font color="#888888"><div><br></div><div>Benoit</div></font></span><div><div><div><br>EOn Oct 2, 2013, at 10:55, Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:<br>





<br></div><blockquote type="cite"><div><div dir="ltr">fat arrow does not add any capabilities but create the need to be sure about the context.<div><br></div><div>In use strict fat arrow will bring a lovely `undefined` wich is undesired so nothing is solved in there.</div>






<div>You need to be sure that the function/closure that is defining the fat arrow is doing it in a `this` context you expect and I wonder how many developers will fall into a `this` hell instead  of "_callback hell_" forced to define fat arrows inside functions such:</div>






<div><br></div><div>```javascript</div><div>(function(){</div><div><br></div><div>this.method = () => alert(123);</div><div><br></div><div>}).call(theDesiredContext);</div><div>```</div><div><br></div><div>The good part is that I've already written about so many pattern able to solve many common mistakes fat arrow will introduce so at least for me this will be a good reference to solve those mistakes/problems later on in the future.</div>






<div><br></div><div>Not much to add if not please read again your first answer to my question, something not just me found not just rude.</div><div><br></div><div>I've asked a question, a honest one, trying to understand. I wasn't trolling and I write real code so your "virtually nobody use that" approach is my daily basis code which is "virtually a better architecture for my needs" that I strongly hope W3C won't ever decide to get rid of because it avoids massive, expensive, pointless usage of extra objects, GC operations, and amount of RAM.</div>






<div><br></div><div>Google is usually very keen to these problems, handleEvent solve an infinity of them at once, developers should just learn how convenient this approach could be for mostly all their DOM based tasks and why not, even more.</div>






<div><br></div><div>Best Regards</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 10:46 AM, Tab Atkins Jr. <span dir="ltr"><<a href="mailto:jackalmage@gmail.com" target="_blank">jackalmage@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>On Tue, Oct 1, 2013 at 7:35 PM, Andrea Giammarchi<br>
<<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:<br>
> setTimeout accept extra arguments ... I write JavaScript that uses this<br>
> feature.<br>
><br>
> `setTimeout(callback, delay, arg1, arg2, argN, evenAnObject);`<br>
><br>
> so fat arrow does not solve much here, I can use self as first argument and<br>
> I am good.<br>
><br>
> `forEach` and all other arrays accept a second argument<br>
><br>
> `array.forEach(doStuff, boundContextObject);`<br>
><br>
> so fat arrow does not solve a thing in mostly all Array extras.<br>
<br>
</div>Having the capability to set 'this' (or pass the current this as a<br>
plain argument) doesn't make it any more convenient.  'this' still<br>
isn't captured by the closure like every other variable is, which is<br>
confusing.  As David said, being forced to pollute the signature of<br>
every standard callback-taking function with this argument is just<br>
silly.  As Claude and others have said, the silly 'this'-rebinding<br>
kludges we have to adopt *everywhere* just to work around this feature<br>
of JS are ridiculous and fragile.  Automatic 'this' binding is very<br>
convenient in some places.  In others, it's very inconvenient.  Arrow<br>
functions give us something better suited for those latter cases.<br>
<div><br>
> for **DOM** I use handlers as specified by **W3C** so that `{handleEvent:<br>
> function () {this}}` works better than any mess I could create with<br>
> callbacks that I won't be unable to remove later on (as I've said) ...<br>
<br>
</div>Virtually nobody does this, and newer interfaces specified with the<br>
WebIDL 'callback' type don't accept it at all.<br>
<div><br>
> so I<br>
> can use `removeEventListener(this)` in every method handled by that object.<br>
<br>
</div>I didn't mention event listeners, actually.  There are lots of other<br>
things that take callbacks besides event listeners.<br>
<div><br>
> So I actually wonder what kind of JavaScript **you** write because this was<br>
> a honest question but probably ... people not familiar with JS are the<br>
> answer: since developers ignore part of JS specs available since every then<br>
> we need a fat arrow to break old syntax to make the creation of self bound<br>
> function easier.<br>
><br>
> This would be already an answer so thanks for participating.<br>
<br>
</div>Wow, that's pretty rude.<br>
<span><font color="#888888"><br>
~TJ<br>
</font></span></blockquote></div><br></div>
</div></blockquote></div></div><div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>es-discuss mailing list</span><br><span><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a></span><br>





<span><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a></span><br></div></blockquote></div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>