JSON parser grammar
Christian Plesner Hansen
christian.plesner.hansen at gmail.com
Thu Jun 4 09:41:08 PDT 2009
> In releasing the IE8 JSON support most of the problem reports we received weren't related to differences between the IE8 implementation and json2.js. We actually discovered that jason2.js was not as widely used as we thought. Most of the issues we received involved encoding/decoding differences between our implementation (and jason2.js) and other encoders that applications were using. We also encountered issues where people were using the jason2 API names but applying them to differing, home grown APIs encoders/decoders.
Great, it sounds like there is no reason to expect any problems from
conforming to the spec. I have filed the incompatibilities as a bug
against our implementation.
What I mean when I say that it increases complexity is that having
different interpretations of something that otherwise appears to be
the same thing adds to the cognitive overhead of using the language.
With 'eval' and 'JSON.parse' you have two functions that behave
deceivingly similarly, and that take similar input. Big obvious
differences between the two are easy to deal with but making subtle
differences between them invites confusion, in particular in this case
because there is already several different interpretations of number
literals in different contexts.
The original post and this current discussion illustrates my point:
subtle differences invite confusion.
More information about the es-discuss