Revisiting Decimal

Kris Zyp kris at sitepen.com
Wed Jan 14 21:32:42 PST 2009


-----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-----



More information about the Es-discuss mailing list