On Jan 14, 2009, at 7:38 PM, Kris Zyp wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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();
};
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.
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.
We already agree that the decimal-double comparison will always be
false.
No, only some for ==. See http://intertwingly.net/stories/2008/08/27/estest.html
:
1.5m == 1.5 true
The point is that this is representative of real world code
that benefits more from the treatment of decimals as numbers.
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 :-).
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.
/be
Kris
/be
- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklur9AACgkQ9VpNnHc4zAzlxwCgpKOVIUfUvIZpdYGOOTC3c2vp
LDIAmgLvpzAW8500idQvyTFaXQ4+eRPv
=cn6y
-----END PGP SIGNATURE-----
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
