Revisiting Decimal

Kris Zyp kris at
Wed Jan 14 19:38:56 PST 2009

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 parses (at least some, if not
all) numbers to Java's BigDecimal. 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.
> Our parser function would need to add support for "decimal"
> (line 32)
>> You're right, this parser would need to be extended. But if
>> typeof
> 1.1m == "number", then str2ob around line 52 might incorrectly call
>  Number on a decimal string literal that does not convert to double
>  (which Number must do, for backward compatibility), or else return
> a double NaN (not the same as a decimal NaN, although it's hard to
> tell -- maybe impossible?).
>> It seems to me you are assuming that decimal and double convert
>> to
> and from string equivalently. This is false.
> Actually there are numerous situations in the graphics packages
> where a decimal should be acceptable for defining coordinates,
> scaling, etc.:
>> Only if never compared to a double. How do you prevent this?
We already agree that the decimal-double comparison will always be
false. The point is that this is representative of real world code
that benefits more from the treatment of decimals as numbers.

> Charting also has a number of places where decimals should be an
> acceptable form of a number:
> For example:
>  (line 22)
>> I will look at these later as time allows, pending replies on
> above points.
> Again, I understand there are difficulties with typeof 1.1m
> returning "number", but in practice it seems we would experience
> far more pain with "decimal".
>> Trouble for you Dojo maintainers but savings for users. You may
> have to do a bit more work to avoid imposing bugs on your users.
> That's life in the big Dojo city.
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.
Dojo covers a very broad swath of topics. Do you really think real
world JS is that much different than Dojo's?

>> /be

- --
Kris Zyp
(503) 806-1841
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

More information about the Es-discuss mailing list