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

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Oct 2 21:23:07 PDT 2013


just because you mentioned it, I've implemented a 1:1 EventTarget ES3
compatible interface a while ago and the code is using a "recycle 3
functions to rule them all"* approach based on a simple Python style
without requiring bind, fat arrow, anything that fix the context in any
given method.

https://github.com/WebReflection/event-target/blob/master/build/event-target.max.js

The RAM is linear, GC has almost nothing to do in there, the mixin is
reusable everywhere either borrowed or inherited.

If you were lookign for some example where fat arrow won't be even an
option, this is a great example I guess.

Best Regards


* all but frozen or not extensible objects



On Wed, Oct 2, 2013 at 6:35 PM, Benoit Marchant <marchant at mac.com> wrote:

> 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 <andrea.giammarchi at gmail.com>
> 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 <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
>>>>
>>>>
>>>
> _______________________________________________
> 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/c916276a/attachment-0001.html>


More information about the es-discuss mailing list