3 ms·

Yes, that would be great. The problem is that JSON doesn't actually provide this. One of the most important aspects of a universal format is in my opinion the

Yes, that would be great. The problem is that JSON doesn't actually provide this. One of the most important aspects of a universal format is in my opinion the ability to rely on the fact that when I store a value on one system, that I retrieve the same value when I read it back on another. JSON doesn't even do this for numbers. The documentation explicitly makes it undefined as to what the precision is. I might be able to store and retrieve the value 1099511627776 using one JSON implementation but when using another, I may get a different value.

theamk 6y ago
Yes, the fact that JSON only does floats is annoying. It is especially bad when I want to store large, high precision numbers, like microsecond timestamps. The right approach is to treat "high precision floating point numbers" as just another type which cannot be represented by JSON natively, and thus store it as a string. After all, we cannot store dates, binary data or 128-bit integers in JSON either. You might argue that JSON should support doubles, and dates, and binary strings, and a ton of others -- but this will make it much less portable. If you add a "high precision float" type, then every parser ever will need to support it. Right now, there is a JSON parsers entirely implemented in a single 3000-line C89 file with no external dependencies. This would be impossible to do with bigger library of data types.
- 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 ago
    What 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 ago
      I 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?

theamk 6y ago

Yes, the fact that JSON only does floats is annoying. It is especially bad when I want to store large, high precision numbers, like microsecond timestamps. The right approach is to treat "high precision floating point numbers" as just another type which cannot be represented by JSON natively, and thus store it as a string. After all, we cannot store dates, binary data or 128-bit integers in JSON either. You might argue that JSON should support doubles, and dates, and binary strings, and a ton of others -- but this will make it much less portable. If you add a "high precision float" type, then every parser ever will need to support it. Right now, there is a JSON parsers entirely implemented in a single 3000-line C89 file with no external dependencies. This would be impossible to do with bigger library of data types.

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 ago
  What 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 ago
    I 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?