what kind of problem is this fat arrow feature trying to solve ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Oct 2 16:18:37 PDT 2013


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 <gundersen at gmail.com>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" <andrea.giammarchi at gmail.com>
> 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 <gundersen at gmail.com>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 <
>>> andrea.giammarchi at gmail.com> 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 <marchant at mac.com>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 <
>>>>> andrea.giammarchi at gmail.com> 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. <jackalmage at gmail.com>wrote:
>>>>>
>>>>>> On Tue, Oct 1, 2013 at 7:35 PM, Andrea Giammarchi
>>>>>> <andrea.giammarchi at gmail.com> 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
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131002/687aa21f/attachment-0001.html>


More information about the es-discuss mailing list