undefined | Better HN

0 pointsgeoelectric8y ago0 comments

The big deal of an arrow function, brevity aside, is that it inherits the value of 'this' from the scope that creates it. Regular functions do not, so to use them as first-class functions you often have to bind before passing, pass around thisObjs for rebinding, do a 'that = this' type trick, etc.

Same goes for 'arguments', though that comes up less. Basically, they're much more representative of a simple lambda than a classical function.

0 comments

erikpukinskis8y ago

What's wrong with explicitly binding the scope? I really like that in JavaScript you have to be explicit about that kind of thing.

haimez8y ago

I think the problem with "this" is that you are trying to recreate classes instead of passing it as a parameter, or using currying. Arrow functions might be slightly more intuitive to intention, but the problem is still there. The implicit nature of "this" in JS is always worse than any explicitly controlled alternative.

mercer8y ago

The syntax of the arrow function does a great job of making this explicit too. On top of that it offers 1) brevity/ease of use, and 2) standardization.

From my experience at least, binding to the outer/creating scope is something I do very often, and as far as I know my use of JS is pretty idiomatic.

Concerning 1, being able to use terser, clearer syntax for something I do so often is a huge win, and in regards to 2, it's nice to see an arrow function and to immediately know what this means, and hella better than having to search for a .bind(), var self = this, var that = this, Car.method(), etc, all equally valid as an approach, and depending entirely on the whims of the programmer behind this code.

geoelectricOP8y ago

I actually find it much more clear for this to be set at the place you see the function defined in code--assuming you know what this is in the wrapping scope, you know exactly what it will be in this scope. Technically a bind is more explicit but in practice the bind tends not to happen where the function is defined so you have to go fishing around the code path for it.

And honestly, the sugar often speaks to readability as well. Compare myArray.every(function (x) { return x; }); with myArray.every(x => x).

erikpukinskis8y ago

The first is more readable. It uses more common tokens, and is therefore more easily recognizable. You're confusing brevity for readability.

I don't understand your scope preference. These seem the same to me:

  family.findEldestFirst(person => this.isRoyal() && person.name == "Kate")

  family.findEldestFirst(isPrincess.bind(family))

  function isPrincess(person) {
    return this.isRoyal() && person.name == "Kate"
  }

11 tokens vs 16, same order of magnitude. Second one has an explicit return, which is good for readability. Shorter lines, to which is better for readability. Also relies on fewer control structures, which is good for readability. No need to understand the =>/-> distinction, which is very subtle and beginners won't know about it. To me I'd rather just learn functions and closures and be done with it.

... And frankly I think using "this" that way in either case is not a win. I'd rather make family its own argument to isPrincess:

  family.findEldestFirst(isPrincess.bind(null, family))

  function isPrincess(family, person) {
    return family.isRoyal() && person.name == "Kate"
  }

Mm. Dat explicitness. Anyway... I think I'm not understanding you. How is this forcing your hand in terms of where you bind the scope?

Franky, my sense is that the people who like ES6 and promises are people who are just allergic to writing named functions. Named functions make callback hell go away, and they solve all the problems these arrow functions do. Somehow people think it's bad form to define lots of functions. But defining functions is my job. :) It doesn't bother me.

My sense is it's just Rubyists who miss Ruby and think "more Rubyish" is better. I sympathize because my path was BASIC -> PHP -> C# -> Ruby -> JavaScript. But I think it is a mistake to try to bring your old idioms to a new language.

... and if I wanted to reduce character count above all else, I'd just go use PERL.

j / k navigate · click thread line to collapse

0 comments

erikpukinskis8y ago

What's wrong with explicitly binding the scope? I really like that in JavaScript you have to be explicit about that kind of thing.

haimez8y ago

mercer8y ago

The syntax of the arrow function does a great job of making this explicit too. On top of that it offers 1) brevity/ease of use, and 2) standardization.

From my experience at least, binding to the outer/creating scope is something I do very often, and as far as I know my use of JS is pretty idiomatic.

geoelectricOP8y ago

And honestly, the sugar often speaks to readability as well. Compare myArray.every(function (x) { return x; }); with myArray.every(x => x).

erikpukinskis8y ago

The first is more readable. It uses more common tokens, and is therefore more easily recognizable. You're confusing brevity for readability.

I don't understand your scope preference. These seem the same to me:

  family.findEldestFirst(person => this.isRoyal() && person.name == "Kate")

  family.findEldestFirst(isPrincess.bind(family))

  function isPrincess(person) {
    return this.isRoyal() && person.name == "Kate"
  }

... And frankly I think using "this" that way in either case is not a win. I'd rather make family its own argument to isPrincess:

  family.findEldestFirst(isPrincess.bind(null, family))

  function isPrincess(family, person) {
    return family.isRoyal() && person.name == "Kate"
  }

Mm. Dat explicitness. Anyway... I think I'm not understanding you. How is this forcing your hand in terms of where you bind the scope?

... and if I wanted to reduce character count above all else, I'd just go use PERL.

j / k navigate · click thread line to collapse