Some JavaScript implementations can't handle keywords as property names.
e.g. in Safari:
var a = { new: 'Monkey' }
fails. Thus the required quotes in the JSON spec.
e.g. in Safari:
var a = { new: 'Monkey' }
fails. Thus the required quotes in the JSON spec.
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.
"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.)
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.
var a = { foo:bar : 'Monkey' }