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

81–90 of 172 posts

Re: BigInt Shipping in Firefox

#81

Post by 3JPLW »

jshowa3 wrote: post #55
anchpop wrote: post #35

Earlier quoted context omitted.

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.

Amusingly the drama continued with a new post:

> censoring my comment will not resolve the inherent dishonesty of this article!!!

Even more amusingly, the commenter's name links to disney.com. Or perhaps it is a strange new astroturfing campaign.

Re: BigInt Shipping in Firefox

#82

Post by recursive »

tyingq wrote: post #61
zamadatix wrote: post #36

Earlier quoted context omitted.

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

Python3 mucked with built in types...

I don't think monkey patching is really common in any version of python. I've not seen it done anywhere.

Re: BigInt Shipping in Firefox

#83

Post by joliv »

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

And Swift! https://docs.swift.org/swift-book/LanguageGuide/Extensions.h...

Re: BigInt Shipping in Firefox

#85

Post by tyingq »

recursive wrote: post #82
tyingq wrote: post #61

Earlier quoted context omitted.

Python3 mucked with built in types...

I don't think monkey patching is really common in any version of python. I've not seen it done anywhere.

Talking about the intro of bytes, bytearrays and the not quite the same types that were backported to 2.x

Re: BigInt Shipping in Firefox

#87

Post by loeg »

cpeterso wrote: post #78

BitInt's "n" suffix appears to stand for "numeric", but that seems confusing when typeof 1 === "number" and typeof 1n === "bigint" . Why not an "i" suffix for "integer"? I understand that a "b" suffix is probably reserved in case JavaScript adds support for binary literals. https://tc39.github.io/proposal-bigint/#prod-BigIntLiteralSu...

1i is a bit more difficult to read than 1n in many fonts. I don't think any numeral is plausibly confused with n, so 'iNt' makes some sense as a suffix IMO.

Re: BigInt Shipping in Firefox

#88

Post by krispbyte »

Once I was working with a database with large integer ids loading them through json and showing them in the browser. There was a bug where ids didn't match when updating a record. The issue was that the json decoder for Javascript didn't handle large numbers, so an id like 12345678901234567 would show up as 12345678901234568. That was fun to debug.

I wonder if the interpreters will convert between BigInts and small ints automatically now? The backend side was PHP and it did so we never noticed the problem there.

Re: BigInt Shipping in Firefox

#89

Post by matthewbauer »

cpeterso wrote: post #78

BitInt's "n" suffix appears to stand for "numeric", but that seems confusing when typeof 1 === "number" and typeof 1n === "bigint" . Why not an "i" suffix for "integer"? I understand that a "b" suffix is probably reserved in case JavaScript adds support for binary literals. https://tc39.github.io/proposal-bigint/#prod-BigIntLiteralSu...

Maybe to avoid confusion with mathematical imaginary notation.

Re: BigInt Shipping in Firefox

#90

Post by tynorf »

krispbyte wrote: post #88

Once I was working with a database with large integer ids loading them through json and showing them in the browser. There was a bug where ids didn't match when updating a record. The issue was that the json decoder for Javascript didn't handle large numbers, so an id like 12345678901234567 would show up as 12345678901234568. That was fun to debug. I wonder if the interpreters will convert between BigInts and small i…

This is one reason why people use strings for IDs in JSON, even if they are actually integers.
Post reply on HN