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

51–60 of 172 posts

Re: BigInt Shipping in Firefox

#51

Post by tzs »

anoncake wrote: post #38
acdha wrote: post #13

Earlier quoted context omitted.

Yeah, the Chrome team basically recommended not to, favoring using something like Babel instead: https://developers.google.com/web/updates/2018/05/bigint#pol...

> and they are also making it infeasible (in most cases) to transpile BigInt code to fallback code using Babel or similar tools. That doesn't sound like a recommendation.

Yeah. The recommendation is to write your code now making explicit calls to a specific bigint library. Later, when the JavaScript in the browsers you need to target has built in bigint support, Babel can replace your library calls with code that uses the built in bigints.

For this to work, you need a library whose bigint behavior either exactly matches the built in implementation, or whose deviations are known and can reasonably be account for when translating to built in bigints.

The library they recommend is a JavaScript translation of their implementation of built in bigints, so should match numerically what the built in implementation does.

There may be other libraries that would be suitable, but it would be nice if everyone agreed on just one for this so that when the time comes to use Babel or similar to replace the library calls with use of the built ins, it only has to deal with one library.

Re: BigInt Shipping in Firefox

#52

Post by jchw »

wvenable wrote: post #49
jchw wrote: post #47

Earlier quoted context omitted.

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.

I’m super strongly against this concept actually, which you might gather from mention of lodash.

Re: BigInt Shipping in Firefox

#53

Post by badosu »

mikepurvis wrote: post #41
zamadatix wrote: post #36

Earlier quoted context omitted.

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

For pretty much the past decade (specially the last few years) I feel the culture has shifted to consider core monkey patches as a pretty bad practice.

Re: BigInt Shipping in Firefox

#54

Post by sbr464 »

metalliqaz wrote: post #46
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'`

That’s what we did for our financial and technical (science/math) backend services that use node.js. We just don’t use the built-in number/float libraries, instead using an abstraction library based on bignumber.js/decimal.js etc, consistently.

Re: BigInt Shipping in Firefox

#55

Post by jshowa3 »

anchpop wrote: post #35
jshowa3 wrote: post #28

What's with the comment at the end of the blog entry? lol.

I think the comment has been deleted, do you remember what it was?

Basically, somebody left a comment saying the author was wrong and didn't know what he was talking about in a very aggressive way without demonstrating where it was wrong and why.

Sorry for the drama. I know its off topic, but its all I can contribute since I know very little about the implementation of base data types.

Re: BigInt Shipping in Firefox

#57

Post by hombre_fatal »

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…

By that logic, you should also test if `a` is a string that can be parsed into a number/bigint as well. Or if it's a Uint8Array that you can decode into a number/bigint.

But that's not how you write software. In an application, you have a canonical representation that you pass through your business logic.

Re: BigInt Shipping in Firefox

#58

Post by weberc2 »

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.

If people could muck with builtins in Python, they would. And worse, they'd do it with inheritance and metaclasses. I say this as a Python dev.

Re: BigInt Shipping in Firefox

#59

Post by hombre_fatal »

badosu wrote: post #53
mikepurvis wrote: post #41

Earlier quoted context omitted.

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

For pretty much the past decade (specially the last few years) I feel the culture has shifted to consider core monkey patches as a pretty bad practice.

Sure, but it's also a bad practice in Javascript.

Re: BigInt Shipping in Firefox

#60

Post by coolreader18 »

jchw wrote: post #52
wvenable wrote: post #49

Earlier quoted context omitted.

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.

I’m super strongly against this concept actually, which you might gather from mention of lodash.

I think they were making a joke.
Post reply on HN