3 ms·

> `indices.map(myObjectArr.at)` That works in this case, but eta-reduction is not generally safe in Javascript due to the variadic nature of many functions, so

> `indices.map(myObjectArr.at)` That works in this case, but eta-reduction is not generally safe in Javascript due to the variadic nature of many functions, so I wouldn't recommend it in production code. For example `indices.forEach(console.log)` does not work as one would expect.

antris 5y ago
Better a function that works in some cases than not having a function at all. Also, by using TypeScript definitions you pretty much always know what's coming in and going out and VS Code will yell at you if you're trying to do something stupid.
- e1g 5y ago
  A function that works in some cases will be a nightmare to debug. The pattern of `indices.map(myObjectArr.at)` is discouraged in JS because it often fails in unexpected ways. For example - ["1","2"].map(parseFloat) // works as expected ["1","2"].map(parseInt) // nope
  - antris 5y ago
    I've learned ages ago that parseInt cannot be used like this, so it's not a problem for me, but I thought linters already take care of this case? Also I wasn't talking about using parseInt, a broken function like this so I'm not sure what the quirks of old, widely known bad parts of Javascript have to do with using functions as arguments, which is one of the most powerful features of the language.
    - Fatalist_ma 5y ago
      There's nothing broken about parseInt. The problem is, it can take a second argument(radix), and .map will feed it current item's index as the second argument(and the whole array as the third, but that one will get ignored). const arr = ['1','2','3']; arr.map(parseInt) is equivalent to: [ parseInt('1', 0, arr), parseInt('2', 1, arr), parseInt('3', 2, arr) ];
      - antris 5y ago
        I know why it works this way. I'm not claiming it has a bugged implementation, I'm saying it's broken by design.
- benjaminjackman 5y ago
  TypeScript definitions don't block and VS Code does not warn for `indices.forEach(console.log)` When using eta-reduction in Javascript both functions and all their (optional) arguments have to be known by the programmer and future programmers, instead of needing to know only the argument-slots being used by (x,y,...) => ... It also defends / insulates against more parameters being added in the future. Additionally, the way `this` in javascript works (or doesn't for a lot of callbacks) also pushes against using eta-reduction.
  - antris 5y ago
    >TypeScript definitions don't block and VS Code does not warn for `indices.forEach(console.log)` Sure, it's a valid way of logging all the arguments that pass through forEach. I don't see a problem here? >When using eta-reduction in Javascript both functions and all their (optional) arguments have to be known by the programmer and future programmers, instead of needing to know only the argument-slots being used by (x,y,...) => ... My VSCode setup shows all arguments of functions automatically. Also, I always avoid optional arguments in my code and writing functions that take in a variable amount of arguments or arguments of different types. I always refactor these out of my codebase. >Additionally, the way `this` in javascript works (or doesn't for a lot of callbacks) also pushes against using eta-reduction. `this` is another smell that I always avoid using in my codebase, and refactor code that uses it to work without `this`. I thought `this` being harmful is common knowledge?
- jakelazaroff 5y ago
  That won’t work in this case. TypeScript won’t yell at you if you pass a function that doesn't use all its arguments. If a second number argument is ever added to `at`, your code using it this way will break and TypeScript will not warn you. This blog post explains why what you’re proposing is dangerous: https://jakearchibald.com/2021/function-callback-risks/#typescript-doesnt-solve-this https://jakearchibald.com/2021/function-callback-risks/#type...
  - antris 5y ago
    I guess I'm then somehow doing subconscious mental gymnastics to prevent this, because me and several of my colleagues have coded like this for years and it hasn't been a problem even once.

antris 5y ago

Better a function that works in some cases than not having a function at all. Also, by using TypeScript definitions you pretty much always know what's coming in and going out and VS Code will yell at you if you're trying to do something stupid.

e1g 5y ago
A function that works in some cases will be a nightmare to debug. The pattern of `indices.map(myObjectArr.at)` is discouraged in JS because it often fails in unexpected ways. For example - ["1","2"].map(parseFloat) // works as expected ["1","2"].map(parseInt) // nope
- antris 5y ago
  I've learned ages ago that parseInt cannot be used like this, so it's not a problem for me, but I thought linters already take care of this case? Also I wasn't talking about using parseInt, a broken function like this so I'm not sure what the quirks of old, widely known bad parts of Javascript have to do with using functions as arguments, which is one of the most powerful features of the language.
  - Fatalist_ma 5y ago
    There's nothing broken about parseInt. The problem is, it can take a second argument(radix), and .map will feed it current item's index as the second argument(and the whole array as the third, but that one will get ignored). const arr = ['1','2','3']; arr.map(parseInt) is equivalent to: [ parseInt('1', 0, arr), parseInt('2', 1, arr), parseInt('3', 2, arr) ];
    - antris 5y ago
      I know why it works this way. I'm not claiming it has a bugged implementation, I'm saying it's broken by design.
benjaminjackman 5y ago
TypeScript definitions don't block and VS Code does not warn for `indices.forEach(console.log)` When using eta-reduction in Javascript both functions and all their (optional) arguments have to be known by the programmer and future programmers, instead of needing to know only the argument-slots being used by (x,y,...) => ... It also defends / insulates against more parameters being added in the future. Additionally, the way `this` in javascript works (or doesn't for a lot of callbacks) also pushes against using eta-reduction.
- antris 5y ago
  >TypeScript definitions don't block and VS Code does not warn for `indices.forEach(console.log)` Sure, it's a valid way of logging all the arguments that pass through forEach. I don't see a problem here? >When using eta-reduction in Javascript both functions and all their (optional) arguments have to be known by the programmer and future programmers, instead of needing to know only the argument-slots being used by (x,y,...) => ... My VSCode setup shows all arguments of functions automatically. Also, I always avoid optional arguments in my code and writing functions that take in a variable amount of arguments or arguments of different types. I always refactor these out of my codebase. >Additionally, the way `this` in javascript works (or doesn't for a lot of callbacks) also pushes against using eta-reduction. `this` is another smell that I always avoid using in my codebase, and refactor code that uses it to work without `this`. I thought `this` being harmful is common knowledge?
jakelazaroff 5y ago
That won’t work in this case. TypeScript won’t yell at you if you pass a function that doesn't use all its arguments. If a second number argument is ever added to `at`, your code using it this way will break and TypeScript will not warn you. This blog post explains why what you’re proposing is dangerous: https://jakearchibald.com/2021/function-callback-risks/#typescript-doesnt-solve-this https://jakearchibald.com/2021/function-callback-risks/#type...
- antris 5y ago
  I guess I'm then somehow doing subconscious mental gymnastics to prevent this, because me and several of my colleagues have coded like this for years and it hasn't been a problem even once.