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

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Oct 2 14:35:05 PDT 2013


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/01a99abc/attachment.html>


More information about the es-discuss mailing list