11–20 of 172 posts
Anyone knows how does bigint serialization and deserialization to JSON look like in practice in Chrome and Firefox?
I feel sorry for whoever has to write the polyfill for this...
https://developers.google.com/web/updates/2018/05/bigint#pol...
I'm curious why this wasn't shipped as a replacement of the existing Number type implementation, instead of this new type and syntax.
Also, I'm assuming there are performance issues with using bigints.
I'm curious why this wasn't shipped as a replacement of the existing Number type implementation, instead of this new type and syntax.
Anyone knows how does bigint serialization and deserialization to JSON look like in practice in Chrome and Firefox?
I'm curious why this wasn't shipped as a replacement of the existing Number type implementation, instead of this new type and syntax.
Because Numbers in javascripts are floats, and not allowing floats in numbers would be a serious backward compatibility issue. Also, I'm assuming there are performance issues with using bigints.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I feel sorry for whoever has to write the polyfill for this...
JS already has a Uint8Array, so bignum libraries are easy. (Let me tell you though, there were JS bignum libraries before Uint8Array, and they were, ahem, “interesting.” I think a popular one built a byte-array abstraction on top of hex-encoded strings, and then built bignums on that.)
Actually supporting the literal syntax or the operators via a plain library is impossible; but you can just do it the other way around: encourage developers to use a bignum library (for now), and have said library just “bake down” to native BigInts when they’re available.
Since everybody until now who was using bignums in JS was using them through a library, this won’t be a hard change to make.
(And it’s already been done! https://www.npmjs.com/package/big-integer now bakes down to native BigInts when it can.)
As for the brazen developers who start writing code to directly use the native BigInt... I suppose they’ll have to have two versions of their compiled code units in their minified blob, with a loader shim that evals out the version of the class/module that does/doesn’t use bigints. Maybe we’ll see an JS-pipeline pass to generate this. (I’m not a JS dev, so I’m not sure if there’s already support for this kind of thing.)
There are important real use cases for this. I authored an implementation of the FNV64 hash function[1] at my last job. I needed to use the BigInteger.js[2] library. It truly surprised me that Javascript in 2018 did not support something so simple as 64-bit integers.
[0]: https://tc39.github.io/proposal-bigint/
I feel sorry for whoever has to write the polyfill for this...
Bignums themselves are actually pretty easy to implement as a plain library, provided your language has a uint8-array type (not just a String type, which might require the content be utf-8 valid, or might only have facilities to operate on codepoints, or might cut the data off at the first NUL.) JS already has a Uint8Array, so bignum libraries are easy. (Let me tell you though, there were JS bignum libraries before U…
Can't you rewrite the syntax into something usable at runtime? Not that it were a good idea.