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 <b...@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é _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development