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

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Oct 2 11:14:03 PDT 2013

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131002/b5e19889/attachment.html>

More information about the es-discuss mailing list