3 ms·
My point was that JSON doesn't even reliably store _integers_. If you could only store a single datatype outside of strings, it should be integers, and JSON doe
by lokedhs 6y ago
My point was that JSON doesn't even reliably store _integers_. If you could only store a single datatype outside of strings, it should be integers, and JSON doesn't even do that.
I'm guessing a lot of software are storing 64-bit integer ID's in a JSON numeric field. How many people know that this is unreliable and when it fails for larger numbers you won't even get an error message but silently get the wrong number?
- theamk 6y agoWhat exactly would you want it to do? Have a separate "float"/"integer" type? This would break roundtriping/comparition on languages which do not distinguish between integers and floating point types representing integers. And it would still make you unhappy, because there are systems out there without simple 64-bit integer support (some examples which come to mind is perl5 on 32-bit machines; TCL; and you know, Javascript before 2019) So JSON has a single numeric type, a float. Yes, you have to remember that you cannot store a 64 bit value there. This is an annoying gotcha. But it does not come from deficiency of the serialization format, it comes from the primary goal: if you want to support many languages, you need to conform to common subset of features. And since there are languages which cannot natively handle 64-bit integers, you should play safe and store those as strings.
- lokedhs 6y agoI would likely only have an integer type. Perhaps even limited to 32 bits. That is because you can't rely on more than that anyway, but if the standard specified it then at least you'd have predictable behaviour. If I can't rely on being able to store a number of certain magnitude, what good is it that some platforms are able to do it?