Then why are you using JSON? JSON is for best practices. Requiring quotes so that some interpreters don't get confused is exactly the type of thing JSON is for.
The js spec says that quotes around property names are optional. Obviously they're needed if the property name is a reserved word.
I don't think it's a good argument to include needless quotes in a data format just so some bad interpreters don't get confused. Fix the interpreter - or just don't use reserved words, or enclose those in quotes if you use them.
Everything adds up. Imagine you were sending a few billion JSON objects a day. Requiring quotes on every single property name is wasteful and unnecessary. It's redundant useless information.
A hack around would be to regexp a replace to add quotes, and then JSON.parse it, but then you may as well just continue using eval, or a parser that doesn't care if you omit quotes, which is a shame.
IMHO, JSON.parse should function exactly as eval does for de-serializing js objects.
Despite the name, JSON is not isomorphic to the definition of JSON object literals. It is by design a subset. This provides both future-proofing against later changes in ECMAScript (adding keywords), and simplifies the grammar for conforming parsers. Simpler grammars mean less opportunity for errors and non-conformant implementations.
"A hack around would be to regexp a replace to add quotes, and then JSON.parse it,"
That is an absolutely terrible, terrible, terrible idea. Do not do that, especially if you're shipping around a "few billion JSON objects a day"! Running regexps over things that require a grammar to fully understand is asking for disaster.
"IMHO, JSON.parse should function exactly as eval does for de-serializing js objects."
The entire purpose is to get away from "eval". How do you like '{"test": window.close()}" in your JSON?
JSON is a cross-language serialization format that was inspired heavily by the fact that Perl, Python, and Javascript had very similar object literals and underlying data structures. It is not simply Javascript in a fancy spec, and you're missing the point if you think it is or treat it like it is. If you're just moving JS around, then ship whatever you like down. Back in the days before anybody had heard of JSON, I used to do that; as long as you're in control of the JS it works fine. (It's useless for communication between different entities, though.)
Please explain why the data format needs quotes around keys.
And yes, I'm just sending data from server to client. I couldn't care less if it conforms to some spec or not. I want an efficient, useful data format.
>> The entire purpose is to get away from "eval". How do you like '{"test": window.close()}" in your JSON?
You're absolutely correct. but that is simple to protect against with a regexp, which is how the json parser at json.org works - regexp it, then eval().
My point is, that for my use case, the native JSON parser will mean an increase in bandwidth. Which is a pain - especially as there isn't a good reason for it.
"This provides both future-proofing against later changes in ECMAScript (adding keywords), and simplifies the grammar for conforming parsers. Simpler grammars mean less opportunity for errors and non-conformant implementations."
If it didn't require quotes, currently valid JSON may not be valid in the future if a new keyword which was use as a JSON object key was used unquoted. And there's the added complexity of supporting both quoted and unquoted keys.
