when do you need to address at runtime so many methods per instance/object ?
I've got the "solve inline" thing but I keep wondering when, where, and why, we need so many inline runtime bound method attachments. Any real code example beside showing how shorter it is ? 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. 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) Thanks On Wed, Oct 2, 2013 at 2:23 PM, Marius Gundersen <[email protected]>wrote: > > 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: > > publish("event", arg1, arg2) > subscribe("event", function(arg1, arg2){ > //do something, e.g. this.something = arg1+arg2 > }, this); > > 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: > > doSomething().then(function(result){ > this.result = result > }, this); > > Or with Knockout: > > this.sum = ko.computed(function(){ > return this.a() + this.b(); > }, this); > > Or with array functions: > > this.array.filter(function(a){ > return a>5; > }).forEach(function(a){ > this.sum += a; > }, this); > > These can all be simplified using the fat arrow: > > subscribe((arg1, arg2) => this.something = arg1 + arg2); > > doSomething().then((result) => this.result = result); > > this.sum = ko.computed(() => this.a() + this.b()); > > this.array.filter((a) => a>5).forEach((a) => this.sum += a); > > 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. > > Marius Gundersen > > > On Wed, Oct 2, 2013 at 8:14 PM, Andrea Giammarchi < > [email protected]> wrote: > >> 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 >> >> > > _______________________________________________ > 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
