4 ms·

In addition to negative index support, a function is more easily composable e.g. converting a list of indices to a list of objects: `indices.map(myObjectArr.at)

• bidirectional 5y ago
  > `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.
• joppy 5y ago
  The alternative being the pretty-much-just-as-short indices.map(i => myObjectArr[i])?
  • antris 5y ago
    Composability is not about syntax but being able to express code as values. You can have complex behaviors from pure functions that are guaranteed to work and can be recomposed into more and more complex structures. It's not a big thing of course with such a simple example, but just try to program without defining a single function and you'll see how tiresome it soon begins to write everything out manually.
• inbx0 5y ago
  That will break with > Uncaught TypeError: Cannot convert undefined or null to object because `myObjectArr.at` doesn't bind `this` to `myObjectArr`. When the internals of `map` call the `at` function, `this` is just `undefined` instead of the original array and it'll throw. Luckily Array.prototype.map takes a second argument just for this purpose indices.map(myObjectArr.at, myObjectArr)
  • antris 5y ago
    Oh wow, I had to try it to make sure. I can't believe how broken the fundamentals of JS are. There should really be a whole new standard library made from ground up without `this`, mutability and all the other legacy stuff.
    • deleted 5y ago
      [deleted]