If you cannot use fat arrow to define prototypes than you cannot recycle functions per each instance neither. 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.
Thanks for your thoughts. On Wed, Oct 2, 2013 at 11:05 AM, Benoit Marchant <[email protected]> wrote: > One could say that JavaScript is an object oriented language where > functions are first class citizen. But JavaScript doesn't have *methods, > *which > in most oo languages have the feature of always running with this being the > object the methods is executed on. > > 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. > > Benoit > > EOn Oct 2, 2013, at 10:55, Andrea Giammarchi <[email protected]> > wrote: > > fat arrow does not add any capabilities but create the need to be sure > about the context. > > In use strict fat arrow will bring a lovely `undefined` wich is undesired > so nothing is solved in there. > 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: > > ```javascript > (function(){ > > this.method = () => alert(123); > > }).call(theDesiredContext); > ``` > > 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. > > Not much to add if not please read again your first answer to my question, > something not just me found not just rude. > > 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. > > 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. > > Best Regards > > > > On Wed, Oct 2, 2013 at 10:46 AM, Tab Atkins Jr. <[email protected]>wrote: > >> On Tue, Oct 1, 2013 at 7:35 PM, Andrea Giammarchi >> <[email protected]> wrote: >> > setTimeout accept extra arguments ... I write JavaScript that uses this >> > feature. >> > >> > `setTimeout(callback, delay, arg1, arg2, argN, evenAnObject);` >> > >> > 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. >> >> Having the capability to set 'this' (or pass the current this as a >> plain argument) doesn't make it any more convenient. 'this' still >> isn't captured by the closure like every other variable is, which is >> confusing. As David said, being forced to pollute the signature of >> every standard callback-taking function with this argument is just >> silly. As Claude and others have said, the silly 'this'-rebinding >> kludges we have to adopt *everywhere* just to work around this feature >> of JS are ridiculous and fragile. Automatic 'this' binding is very >> convenient in some places. In others, it's very inconvenient. Arrow >> functions give us something better suited for those latter cases. >> >> > for **DOM** I use handlers as specified by **W3C** so that >> `{handleEvent: >> > function () {this}}` works better than any mess I could create with >> > callbacks that I won't be unable to remove later on (as I've said) ... >> >> Virtually nobody does this, and newer interfaces specified with the >> WebIDL 'callback' type don't accept it at all. >> >> > so I >> > can use `removeEventListener(this)` in every method handled by that >> object. >> >> I didn't mention event listeners, actually. There are lots of other >> things that take callbacks besides event listeners. >> >> > So I actually wonder what kind of JavaScript **you** write because this >> was >> > a honest question but probably ... people not familiar with JS are the >> > answer: since developers ignore part of JS specs available since every >> then >> > we need a fat arrow to break old syntax to make the creation of self >> bound >> > function easier. >> > >> > This would be already an answer so thanks for participating. >> >> Wow, that's pretty rude. >> >> ~TJ >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
