-----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? > >> It's not a question of more or less. If you let decimals and >> numbers mix, you'll get data-dependent, hard to diagnose bugs. If >> you do not, then you won't (and Dojo maintainers will have to >> work a bit to extend their code to handle decimals -- which is >> the right trade. Recall Mr. Spock's dying words from STII:TWoK >> :-). So you are suggesting that we shouldn't let users pass mix of decimals and numbers even if they explicitly attempt to do so? > > > If that's true, that's fine, I have no problem with Dojo feeling > the pain for the sake of others, but I still find it very > surprising that Dojo code would be so misrepresentative of real > code out there today. > >> It's not necessarily representative. It's not necessarily >> mis-representative. But we need to agree on how decimal as >> proposed compares to number (double) first, since from what you >> wrote above I see misunderstanding. > > > Dojo covers a very broad swath of topics. Do you really think real > world JS is that much different than Dojo's? > >> I have no idea, but this is completely beside the point. Breaking >> typeof x == typeof x => (x == y <=> x === y) for decimal will >> break existing code in data-dependent, hard to diagnose ways. > >> Adding a new typeof code will not depend on the value of a given >> decimal: any decimal will cause control to fall into an else, >> default, or unhandled case, which is strictly easier to debug and >> fix. Plus, any future JS standard with Decimal will be a big >> enough deal that porting will be obligatory and understood, by >> the time browsers adopt decimal. It's not beside my point. If signficantly more real world code will break due to violating the expected invariant of a constant finite set of typeof results (and the expectation that numbers regardless of precision will be typeof -> "number") than those that break due to violating the expected invariant of typeof x == typeof x => (x == y <=> x === y) than I think we would be negligent as language designers to ignore that consideration. I understand the logical concerns, but I would love to see real empirical evidence that contradicts my suspicions. Kris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkluynkACgkQ9VpNnHc4zAx5LgCfWWzZ7s2gGDz0OMS6QrjOMbYy VMIAoLWc9d6ZUqVmY/ma2PygBCXdNgK2 =oUop -----END PGP SIGNATURE----- _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
