Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stage 3 Proposal: Array.prototype.at

tc39.es

Post reply on HN
Print view View original

31–40 of 153 posts

Re: Stage 3 Proposal: Array.prototype.at

#31

Post by e1g »

antris wrote: post #18
bidirectional wrote: post #15

Earlier quoted context omitted.

> `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.

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.

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

Re: Stage 3 Proposal: Array.prototype.at

#32

Post by benjaminjackman »

antris wrote: post #18
bidirectional wrote: post #15

Earlier quoted context omitted.

> `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.

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.

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.

Re: Stage 3 Proposal: Array.prototype.at

#34

Post by jakelazaroff »

antris wrote: post #18
bidirectional wrote: post #15

Earlier quoted context omitted.

> `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.

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.

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/#type...

Re: Stage 3 Proposal: Array.prototype.at

#35

Post by onion2k »

almost wrote: post #22
sfinx wrote: post #19

If I understand this correctly it is to add negative index support to arrays. How will findIndex work when this is introduced? It currently uses -1 as a return value when no element satisfies the testing function.

It’s not adding negative indexes, a negative number will index from the end. So [0, 1, 2, 3].at(-2) === 2

That would mean getting the last element of the array would be [0,1,2,3].at(-1).

I don't like that very much.

Mind you, I don't like the idea of using [0,1,2,3].at(-0) either...

Re: Stage 3 Proposal: Array.prototype.at

#36

Post by jakelazaroff »

onion2k wrote: post #35
almost wrote: post #22

Earlier quoted context omitted.

It’s not adding negative indexes, a negative number will index from the end. So [0, 1, 2, 3].at(-2) === 2

That would mean getting the last element of the array would be [0,1,2,3].at(-1). I don't like that very much. Mind you, I don't like the idea of using [0,1,2,3].at(-0) either...

Don’t think of it as counting from the end of the array — think of it as counting in reverse from the 0th element. .at(1) gets the next element (index 1) while .at(-1) loops around and gets the “previous” element (index 3, in this case).

Or, if it’s more intuitive, you can think of the array index as an unsigned integer where the max is equal to the length of the array. If you try to assign -1 to a uint8, the result will be 255 — the highest possible value (the last index).

Re: Stage 3 Proposal: Array.prototype.at

#38

Post by cxr »

jasonzemos wrote: post #17
playpause wrote: post #14

Earlier quoted context omitted.

New features are added to JavaScript very carefully to avoid breaking existing code on the web. The downside is you often end up with multiple ways to do the same thing, but there are ways to mitigate this, like using a linter to enforce using a modern subset of the language.

That's starting to sound an awful lot more like C++.

No, even then, they're fundamentally different.

An organization can go through and update its C++, because ultimately they're distributing binaries (or doing everything internally and not distributing anything at all).

Web "pages" aren't called that for no good reason. If in 2005 you bought a novel, or some punk writer–artist's printed pamphlet, and now you can't read it because in the meantime some engineers changed a spec somewhere, then that would be a failure, not just in the small, but on a societal level. Just rev the language is something that people who spend 40+ hours in an IDE or programmer's text editor think up when they're used to dealing in SDKs and perpetually changing interdependencies and fixing them and getting paid handsomely for it. But that's not what the Web is. The Web is the infrastructure for handling humanity's publishing needs indefinitely.

To rely upon another observation:

"[This] is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release."

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

Re: Stage 3 Proposal: Array.prototype.at

#40

Post by Slackwise »

eknkc wrote: post #23
wereHamster wrote: post #11

Earlier quoted context omitted.

There is existing code out there which relies on negative indexes to return undefined. Or relies on being able to assign items to negative indexes and then retrieve them, this is perfectly valid code: `a=[];a[-1]=42;console.log('the answer is',a[-1])`. The web tries really hard to be backwards compatible and not break existing code.

Maybe we should re utilize the "use strict"; type of metadata. Something like "use es2021" to enable negative indexes etc.

I've been thinking this for ages.

We need more special contextual comments to change a file or scope to behave better so we can move forward and scrape away all the bad legacy of JS.

Post reply on HN