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

BigInt Shipping in Firefox

wingolog.org

Post reply on HN
Print view View original

41–50 of 172 posts

Re: BigInt Shipping in Firefox

#41

Post by mikepurvis »

zamadatix wrote: post #36
callahad wrote: post #23

Earlier quoted context omitted.

You can define a toJSON property on the BigInt prototype that gets used for serialization: Object.defineProperty(BigInt.prototype, "toJSON", { get() { "use strict"; return () => String(this); } }); Of course you could also serialize to a Number, but that risks losing precision. For example, the Twitter API often returns IDs as both a Number ("id") and a String ("id_str") to safely handle cases where the value might f…

Only in JS do people seem okay with constantly mucking with built-ins.

Ruby has a culture around it too: https://www.justinweiss.com/articles/3-ways-to-monkey-patch-...

And you can get some of the patching effect in any language with uniform function/method calls, though typically with a little more scoping and thus less ability to inflict unexpected side effects: https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax

Re: BigInt Shipping in Firefox

#42

Post by Dylan16807 »

derefr wrote: post #18
philbarr wrote: post #7

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…

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

Or if your String type doesn't do any of those. Javascript strings will happily hold an arbitrary series of 16 bit numbers.

Even when something requires valid code points, you can still easily store arbitrary 8 bit values. Or 15/16/17/20 depending on how fussy you are. Unless you want it to be hacky, it shouldn't be notably worse than an array.

Re: BigInt Shipping in Firefox

#43

Post by dlbucci »

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`...

EDIT: The more I think about it (and the more comments I get), the more I think this might actually be a good thing. I think bigint will probably not be used in places where integer numbers are currently used, and it might be unreasonable to expect code to work with numbers or bigints. In that case, it's actually probably good that you can easily tell the difference using typeof, without requiring some hacky fix like `Array.isArray`.

It does mean that "don't mix numbers and bigints" is going to become very popular JS advice soon.

Re: BigInt Shipping in Firefox

#44

Post by 1f60c »

dlbucci wrote: post #43

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`... EDIT: The more I think about it (and the more comments I get), the more I think this might actually be a good thing. I think bigint will probably not be used in places where integer numbers are currently used, and it might be unreasonable to expect code to work with nu…

What makes you think that, exactly?

Re: BigInt Shipping in Firefox

#45

Post by tzs »

bpye wrote: post #39
M2Ys4U wrote: post #21

Earlier quoted context omitted.

I suppose one could use a replacer[0] when calling JSON.stringify and a reviver[1] when calling JSON.parse [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

You can certainly serialize to a string but knowing when you should revive to a BigInt seems tricky. You could prefix the strings I guess?

How about serializing to an array ["bigint", "170141183460469231731687303715884105727"]? It takes more space, but is easy to recognize, and easy to generalize to other types.

Re: BigInt Shipping in Firefox

#46

Post by metalliqaz »

dlbucci wrote: post #43

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`... EDIT: The more I think about it (and the more comments I get), the more I think this might actually be a good thing. I think bigint will probably not be used in places where integer numbers are currently used, and it might be unreasonable to expect code to work with nu…

It seems to me that in applications where there is widespread use bigint, you would simply be doing `typeof a === 'bigint'`. And, in nearly all other applications, it would remain as simply `typeof a === 'number'`

Re: BigInt Shipping in Firefox

#47

Post by jchw »

dlbucci wrote: post #43

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`... EDIT: The more I think about it (and the more comments I get), the more I think this might actually be a good thing. I think bigint will probably not be used in places where integer numbers are currently used, and it might be unreasonable to expect code to work with nu…

To be fair, it really shouldn’t be conflated with ‘number’ - it isn’t the same thing, the behavior differs. And you can (and probably should) use small helper functions for these kinds of checks, pretty much for this kind of flexibility. Kind of curious what other libs (like lodash) will do.

Re: BigInt Shipping in Firefox

#49

Post by wvenable »

jchw wrote: post #47
dlbucci wrote: post #43

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`... EDIT: The more I think about it (and the more comments I get), the more I think this might actually be a good thing. I think bigint will probably not be used in places where integer numbers are currently used, and it might be unreasonable to expect code to work with nu…

To be fair, it really shouldn’t be conflated with ‘number’ - it isn’t the same thing, the behavior differs. And you can (and probably should) use small helper functions for these kinds of checks, pretty much for this kind of flexibility. Kind of curious what other libs (like lodash) will do.

If you're really going to do it right, that small function should also be published as npm package (isnumeric) that takes at least 2 other packages (isnumber and isbigint) as dependencies.

Re: BigInt Shipping in Firefox

#50

Post by derfniw »

bpye wrote: post #39
M2Ys4U wrote: post #21

Earlier quoted context omitted.

I suppose one could use a replacer[0] when calling JSON.stringify and a reviver[1] when calling JSON.parse [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

You can certainly serialize to a string but knowing when you should revive to a BigInt seems tricky. You could prefix the strings I guess?

Reuse the literal? (postfix with 'n')
Post reply on HN