Revisiting Decimal

Kris Zyp kris at
Thu Jan 15 05:49:06 PST 2009

Hash: SHA1

Bob Ippolito wrote:
> On Wed, Jan 14, 2009 at 9:32 PM, Kris Zyp <kris at> wrote:
>> 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 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.


Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

More information about the Es-discuss mailing list