>-----Original Message----- >From: [email protected] [mailto:es-discuss- >[email protected]] On Behalf Of Christian Plesner Hansen > >(Sorry for the repeat, my first attempt bounced because I wasn't >subscribed to es-discuss)
Please join... > >> The V8 implementation is a pretty early implementation and I would >> consider all of the issues raised here to be bugs in it. > >It is indeed an early implementation but the decision to use the >source parser directly is deliberate. Because of the way json2.js >works anyone currently using it would get our implementation in the >future and I didn't want to change the behavior in subtle ways under >people's feet. > >It's unclear to me from reading this thread if any other browsers >actually implement JSON correctly according to ES5. If none do, how >sure are we that these changes won't break people's programs? The IE8 implementation also started with json2.js as the model and evolved in response to ES5 developments prior to IE8 production release. There are a few variances between the currently shipping IE8 JSON implementation and the current ES5 spec. A couple of these are bugs in our implementation and others are the result of late churn in the E5 specification (some of which we contributed to based upon our IE8 experiences). Almost all the variances deal with API edge cases and unusual situations (for example, a Number wrapper object returned from a stringify replacer function might be rendered as an object rather than a numeric literal). Almost all of the known issues have been found by our internal testing and analysis of the algorithms and haven't shown up in user problem reports. Regardless, we intend to evolve our implementation to strictly conform to the final ES5 spec. as quickly as we can. 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. So far, I think the implementers that have been actively engaged with ES5 development within TC39 have been doing a pretty good job of collaborating to make sure that all our JSON implementations are highly compatible with each other and with the emerging standard. Please feel free to join in. >As for octal literals I agree that they're not a good idea. However, >adding new special cases to avoid them is a cure worse than the >disease. It adds to the complexity of the language in an area that is >already dangerously complex. Octal literals have never been part of the JSON format and support for them by some JSON parsers is likely a side-effect of those parsers use of eval. This sort of implementation accident is exactly the sort of thing we want to make sure doesn't get unnecessarily enshrined in either standards or future implementations. Not supporting JSON octal literals adds no complexity to the ES5 JSON spec. because they are simply not part of the format and are never mentioned. It only adds complexity to implementations if they are trying to reuse their JavaScript lexer (assuming it supports octal constants) to lex JSON text and there are already enough other differences between the JSON and ECMAScript token set that it isn't clear that this is a good idea. Regardless, ES5 lexers are already required to not recognize octal number when operating in strict mode. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
