brendan at mozilla.com
Thu Jan 15 15:28:33 PST 2009
On Jan 15, 2009, at 3:05 PM, Kris Zyp wrote:
> more ambivalent on typeof 1.1m than on the what seems to me to be a
> more obvious mistake of throwing on JSON serialization of decimals.
Good to hear. Ambivalence should not be a stable state, though. If we
can get to typeof agreement, let's do so. It seems to me ambivalence
should mean "no", not "yes".
> [hundreds of cited lines deleted -- please trim when replying. /be]
>> If you really endorse "receiver
>> makes it right", give a spirited and explicit defense.
> JSON already encodes in decimal.
No, you are assuming your conclusion again. "JSON already encodes in
decimal" meaning "JSON encoding writes base ten floating point with
optional exponent numbers" does not employ the same meaning of the
word "decimal" as the decimal type contemplated for Harmony. The
latter has semantics in addition to syntax. JSON's RFC says almost
nothing about semantics.
> Do you want a defense of how a
> receiver should make right what is already right? We can't argue about
> whether JSON should have a more explicit type system. JSON is frozen.
Sorry, seems to me you are ducking again. Please address the
incompatible change from JSON in self-hosted codes and the native
ES3.1 codec encoding only doubles using JSON number syntax, vs. your
proposal where with decimal added to the language we encode decimal
and double as JSON number syntax.
> All decimal use is
> opt-in anyway, there is no breakage for existing code when the VM is
What do you mean by "opt-in"?
If JSON peer Alice starts using decimal and encoding financial data
sent to existing, double-based peer Bob, does Alice lose money? If no,
show how. If yes, then show why such a bug is not a fatal flaw in your
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss