-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bob Ippolito wrote: > 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. Specifying number representations would be far more grievous in terms of creating tight-couplings with JSON data. It is essential that implementations are free to use whatever number representation they desire in order to facilitate a loose coupled interchange. Kris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklvPtIACgkQ9VpNnHc4zAygHwCfZ38UEIK6ZJZDvvmddMlcgMvH ELQAnR8r3Hy25cwG+19BDVmVIw79EBDQ =JZqE -----END PGP SIGNATURE----- _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
