> "Sure" is never an option ;). Our relative confidence comes from our > knowledge of the behavior of various popular json emitters. In > particular, we know of none that emit octal.
It takes just one home-made emitter on a popular site somewhere for this to break down. On the other hand if there are already browsers that never interpret numbers as octal and haven't experienced any problems with it then that's pretty close to "sure". > Since octal syntax will currently be interpreted as decimal on some > browsers and octal on others, even by json.js (since it delegates to > eval), there is no safe way to allow this syntax. By allowing them, > one's JSON.parse is no longer validating. It will not complain about > data that will be interpreted differently by different browsers. That sounds reasonable, though I'm unsure if the value of validation justifies making the language more complex. If we're already in a situation where nobody uses octal numbers in their json then validation would seem unnecessary. > Recall that we felt we needed to add JSON support to the spec because > JS library code cannot provide parsers that are simultaneously fast, > safe, and validating. If all you want is safe and fast, json_sans_eval > is a fine solution that works on existing browsers. I wasn't aware of the validation aspect. Also, I don't know of any truly safe and fast json implementations that work on existing browsers (no offense to json2.js). --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
