Just as a comparison point, in MontageJS we chose to implement the DOM Event Target and Event Listener interfaces on Montage JavaScript objects to avoid adding similar APIs under a different name.
Benoit > On Oct 2, 2013, at 19:18, Andrea Giammarchi <[email protected]> > wrote: > > It's a knockout choice I would say, nothing to do with the fact you cannot > have an `handleEvent` in there. > > Look at [eddy.js](https://github.com/WebReflection/eddy#event-driven-js) or > put in in your project and you could handleEvent all the things, DOM and not > ^_^ > > 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. > > 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 :-( > > Thanks for sharing though, libraries/frameworks are always a good example of > "already got this problem in here". > > br > > >> On Wed, Oct 2, 2013 at 2:55 PM, Marius Gundersen <[email protected]> wrote: >> 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. >> >> Marius Gundersen >> >>> On Oct 2, 2013 11:35 PM, "Andrea Giammarchi" <[email protected]> >>> wrote: >>> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
