[Development] JSON 64 bit int

[André Somers]

Marc Mutz schreef op 11-2-2015 om 16:11:
> On Wednesday 11 February 2015 14:04:59 Bo Thorsen wrote:
>> Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo:
>>> On 11 February 2015 at 12:12, Bo Thorsen <bo at vikingsoft.eu> wrote:
>>>> It's so easy to say we just follow the standard. But I have two current
>>>> projects where my customers say they send me a 64 bit database ID in a
>>>> JSON value. Converting those through a double might work, but can you
>>>> guarantee this?
>>> No, because IEEE754 64-bit floating point numbers can't represent all
>>> 64 bit integers... the right solution, from a JSON point of view, is
>>> not sending a number but a string.
>> Exactly, that's why I wrote "might". You don't know if the number you
>> get is correct or not.
>>
>> But we can't get the string from {"i":1}. You get an empty string if you
>> do toString on the i value.
>>
>> And that's the problem. People have web APIs that return uint64 as a
>> number and I need to get that number. ATM the only way is to read it
>> from the full QByteArray. If the toString would never fail and give me
>> the contents or I can get the bytes from it or add the extra type
>> reading functions - all three would work. The current meagre API is
>> pretty much the only way that doesn't.
> If Qt produces 64-bit integers in its JSON output, then the next bug report
> will (probably rightfully) be that Qt's JSON output cannot be read by some
> JavaScript library X.
>
> That said, if in doubt, follow Postel's Law.
>
So, the setter should probably read something like:

enum ResponsibilityLevel { IAmClueLess, 
IKnowThisIsNotStandardJsonAndWontComplainToQt };
setValue(qint64 value, ResponsibilityLevel responsibility = IAmClueLess);

Assert/throw if responsibility is at IAmClueLess :-)

Actually following Postels law would mean being able to read an Int64, 
but not being able write one right?

André