On Wed, Jan 14, 2009 at 9:32 PM, Kris Zyp <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Brendan Eich wrote: >> On Jan 14, 2009, at 7:38 PM, Kris Zyp wrote: > >> >>>>>> You need to change this in any case, since even though the >>>>>> JSON >>>>> RFC allows arbitrary precision decimal literals, real-world >>>>> decoders only decode into IEEE doubles. You'd have to encode >>>>> decimals as strings and decode them using domain-specific >>>>> (JSON schema based) type knowledge. >> No, every Java JSON library I have seen >> >>> You've seen >> >>> http://www.json.org/json2.js >> >>> It and the json.js alternative JS implementation are popular. >>> json2.js contains >> >>> String.prototype.toJSON = Number.prototype.toJSON = >>> Boolean.prototype.toJSON = function (key) { return >>> this.valueOf(); }; >> > > Of course, there is no decimal support in ES3, there is no other option. >> parses (at least some, if not all) numbers to Java's BigDecimal. >> >>> JSON has nothing to do wth Java, and most implementations do not >>> have Java BigDecimal, so I don't know how it can be relevant. >> > One of the major incentives for JSON is that it is interoperability > between languages. If other implementations in other languages treat > JSON's number as decimal than the assertion that I understood you were > making that JSON number's are being universally expected to be treated > as binary is not true. >> JSON's numbers are decimal, languages that support decimals agree. >> Dojo _will_ convert JS decimal's to JSON numbers regardless of what >> path ES-Harmony takes with typeof, whether it requires a code >> change or not. >> >>> That will break interoperatability between current >>> implementations that use doubles not decimals. >> > How so? And how did all the implementations that use decimals to > interpret JSON numbers not break interoperability?
I'm pretty sure that interoperability is broken when they do this, it's just very subtle and hard to debug. I have the same stance as Brendan here, I've even refused to implement the capability to directly encode decimal as JSON numbers in my simplejson package (the de facto json for Python). If a user of the library controls both ends of the wire, they can just as easily use strings to represent decimals and work with them exactly how they expect on both ends of the wire regardless of what their JSON implementation happens to do. Imagine the person at the other end of the wire is using something like JavaScript or PHP. If the message contains decimals as JSON numbers they can not accurately encode or decode those messages unless they write their own custom JSON implementation. How do they even KNOW if the document is supposed to have decimal precision? What if the other end passes too many digits (often the case if one side is actually using doubles)? If they are passed around as strings then everyone can use the document just fine without any compatibility issues. The lack of a de jure number precision and the lack of a date/datetime type are definitely my biggest grievances with the JSON spec. -bob _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
