Live data from Hacker News

Stage 3 Proposal: Array.prototype.at

tc39.es

81–90 of 153 posts

Re: Stage 3 Proposal: Array.prototype.at

#81

Earlier quoted context omitted.

const leftpad = (str, len, char = ' ') => str.length >= len ? str : (char.repeat(len - str.length) + str); Anybody who installs a dependency instead of writing a one line function is just leaving themselves exposed for no real benefit. Providing the at function outside of the prototype chain like I did above will not incur the cost you mentioned, even in the unlikely case that such calls are the bottleneck of your ap…

Reinventing the wheel is error prone. Noone wants to bloat their code/time with unit tests for all these utility methods. Just look at your at() function, I already spotted a bug, if a numeric string is passed: `([].length + '-1') === '0-1'`

Their example does no argument validation. It doesn't check that arr is array, or that i is an integer, etc. The spec actually addresses the argument validation.

Re: Stage 3 Proposal: Array.prototype.at

#82
post #10

Earlier quoted context omitted.

The problem with JS language development is the mountain of code that it would break if you do anything except append features. array[-1] = “foo” This already works in JS but doesn’t do what you expect and just assigns the property.

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!

Re: Stage 3 Proposal: Array.prototype.at

#83

Earlier quoted context omitted.

Reinventing the wheel is error prone. Noone wants to bloat their code/time with unit tests for all these utility methods. Just look at your at() function, I already spotted a bug, if a numeric string is passed: `([].length + '-1') === '0-1'`

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.

Re: Stage 3 Proposal: Array.prototype.at

#84

const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + i]; Why does the core language need to be extended to incorporate this?

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.

Re: Stage 3 Proposal: Array.prototype.at

#85

JS 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?

Re: Stage 3 Proposal: Array.prototype.at

#86
post #83

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

It is trivial. It requires a few more lines than my example, but my example was intended to show the core use case. All I'm getting in replies is nitpicking about my example case... Can't you just assume when reading that I know how to write some simple guard statements? It's hardly rocket science.

Re: Stage 3 Proposal: Array.prototype.at

#87

JS 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

Honest (possibly stupid) question: Do people working on statistical and probability application never need a numeric type optimized for probability values (i.e. values between 0 and 1 that can get really close to either; for example the really almost certain value of p = 1 - 10^-13)? In the same way that financial application needs a decimal type? I’ve only worked on probability applications at a surface level for a…

Log probabilities are used a bit for this, and most numeric packages (numpy for instance) have special functions for computing log(1+x) which are more accurate when x is tiny.

Re: Stage 3 Proposal: Array.prototype.at

#88
post #78

Earlier quoted context omitted.

Javascript array indexing is a MESS. This array["foo"] = "bar" is valid javascript.

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.

Re: Stage 3 Proposal: Array.prototype.at

#89
post #38

Earlier quoted context omitted.

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…

Your post sounds good... Until you realise that nearly any nontrivial web page from 10+ years ago is broken today... No Flash... Iframes don't work properly anymore... HTTPS servers from 10 years ago are unsupported by todays browsers... Most of the IE hacks no longer work (remember progid:DXImageTransform?)... Any images/resources hosted elsewhere are likely now nonexistent... Plenty of web features have been introd…

> nearly any nontrivial web page from 10+ years ago is broken today

Can you provide some examples? In my experience broken 10+ year old websites is the exception, not the rule. And most of the exception is because flash (which has a workaround; plus most popular flash websites have been ported).

Re: Stage 3 Proposal: Array.prototype.at

#90
post #7
post #2

Am I reading this correctly — it's an alias for arr[i] and str[i]? I know languages like Ruby have arr.at(i), but why?

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])?
Post reply on HN