This will be handy for a multitude of string libs, for example string diffing (fast myers diff, ...)
Stage 3 Proposal: Array.prototype.at
91–100 of 153 posts
Re: Stage 3 Proposal: Array.prototype.at
#92Earlier quoted context omitted.
Why does this make it a mess? Array already has a bunch of properties that aren't elements in the Array that come from the prototype, like join and slice. Your example is just adding a custom property to the array.
Because in most other languages, an array is an enumeration of values. That's it. In Javascript, arrays are actually dictionaries. But not full dictionaries, rather just dictionaries that can have either a string or numeric key. It's messy because an array in javascript isn't just "an array" it's this mismesh of features that are unexpected to a new-to-javascript developer. Unexpected is the enemy of readable code.
No, arrays are just objects with a magic "length" property (technically: a special [[DefineOwnProperty]] internal method which sometimes also mutates "length"). Like objects, they only support strings as keys.
Re: Stage 3 Proposal: Array.prototype.at
#93Earlier quoted context omitted.
Javascript array indexing is a MESS. This array["foo"] = "bar" is valid javascript.
array["at"] = "lunchtime"; Is also valid javascript... And will break functionality in this proposal!
I think this is the point of the stage 3 proposal.
Browser makers start implementing the feature and releasing it in the development and beta versions of their browsers. Then if the users of the experimental features start noticing that webpage break, the proposal will get an update.
If I remember correctly, this exact thing happened to `Array.prototype.flatten` which got renamed to `Array.prototype.flat` after it was realized that the former broke a lot of legacy webpages (and after a long discussion of `Array.prototype.smoosh`[1])
1: https://developers.google.com/web/updates/2018/03/smooshgate
Re: Stage 3 Proposal: Array.prototype.at
#94Earlier 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.
TC39 explicitly rejected this sort of approach a few years ago, because of the unpleasant way it would fork the web. They _did_ automatically clean up some behavior in a module context when you knew you were using a modern JS engine, but they kept that to a minimum.
Unfortunately, I couldn't find any links to articles written at the time about this, but they definitely did consider "use" options or script type="es2021" kinds of options.
Re: Stage 3 Proposal: Array.prototype.at
#95JS urgently needs support for decimals [1] and thus be able to enter sectors such as scientific and financial. V8 + dynamic language + better math support = perfect environment for many applications out there [1] https://github.com/tc39/proposal-decimal
For financial makes sense, but science should be independent of numerical base?
I think the issue isn't the base, but that Javascript stores all numbers as 64-bit floats.
Re: Stage 3 Proposal: Array.prototype.at
#96Earlier quoted context omitted.
yes that is obvious - my point was that the functionality is minimal. with guards: const at = (arr, i) => { if(!(Array.isArray(arr) && typeof i === 'number')) { throw new Error('invalid arguments'); } // same as before }; you wouldn't just commit a single-line function in your code. But there are 10,000 micro-functions that could be in the core of JS. Why bother to add this, especially if it's so easy to implement? T…
Your number guard is insufficient. NaN, infinity, 2.23 are all Number but not supported values for the function. This goes to show that it's NOT trivial to implement in a robust way.
If we're going to nitpick, those are actually all valid values for `arr[i]`... (though, to be fair, they don't exactly do what one might necessarily expect)
Re: Stage 3 Proposal: Array.prototype.at
#97Earlier quoted context omitted.
You seem to be garnering a lot of downvotes without replies so I'll bite: it sounds from your comment like you've never looked into the subdependency tree of those frameworks and meaningful libraries that you list (which seems like it would be hard to miss tbh for anyone that's ever opened up the node_modules directory). Those tiny little libs providing tiny little functions are likely not direct dependencies of your…
I'm aware of that. Unfortunately that's always going to be the case that some people who write libraries you depend on indirectly are not very good at programming and lean heavily on other dependencies to provide basic functionality. That will be the case regardless of how all-encompassing the stdlib is, and is entirely dependent on the culture of practice of the language you're using. JS is both beginner-friendly an…
> That's not going to change with the number of new core features.
I... don't really see why it wouldn't? What's your logic here?
Re: Stage 3 Proposal: Array.prototype.at
#98Earlier quoted context omitted.
Because at some point someone will - and probably has - make a library out of this, adding yet one more to the tens of thousands of files that my cruddy server can't handle already because of the sheer quantity. Plus you're probably missing a few dozen edge cases and optimizations that the native version would incorporate. We wouldn't have been in node_modules dependency hell if they incorporated a few more things in…
> optimizations that the native version would incorporate We shouldn't write stuff in native code for performance... We should write the compiler to detect these and output optimized code.
By "native version", I think that Cthulhu meant building "at" into the JS runtime, not writing "at" as a C extension and compiling it into native code.
Re: Stage 3 Proposal: Array.prototype.at
#99Earlier quoted context omitted.
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)` I've lost count on how many times I've wrote this function manually.
The alternative being the pretty-much-just-as-short indices.map(i => myObjectArr[i])?
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.
Re: Stage 3 Proposal: Array.prototype.at
#100Earlier quoted context omitted.
I'm aware of that. Unfortunately that's always going to be the case that some people who write libraries you depend on indirectly are not very good at programming and lean heavily on other dependencies to provide basic functionality. That will be the case regardless of how all-encompassing the stdlib is, and is entirely dependent on the culture of practice of the language you're using. JS is both beginner-friendly an…
> That's not going to change with the number of new core features. I... don't really see why it wouldn't? What's your logic here?
A famous example: the is-odd and is-even libraries. It's not the kind of function that would be appropriate for a stdlib in my opinion, and yet developers who presumably don't know about the modulo operator incorporate these libraries into their projects at a high enough rate to engender 700,000/week of downloads.
Even with all the basic functions one could hope for being brought into JS' core, there will still be tons of bizarre micro-libraries like these in the npm repository being used by developers who rely on libraries first when it comes to any given feature, because doing so is part of JS culture for the reasons I outlined before.