That seems pretty fragile.
Comments in JSON
91–100 of 180 posts
Re: Comments in JSON
#92A common practice in config files is to comment out whole sections e.g. optional proxy server settings. This sort of multi-line comment is not addressed by this hack
Re: Comments in JSON
#93There is a interview with the inventor of JSON somewhere. In that interview he explained why he did not allow comments in JSON like in XML. He said - if I remember correctly - that it was intentional to not have comments in JSON. The reason way that comments could be misused to add additional information for a parser. For example in XML you could use comments and a special parser could use these comments to create co…
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability." -- Crockford This is horrific design reasoning. It's an authoritarian, presumptuous, "punish everyone in the classroom because one child misbehaves" mentality. Comments would be useful in JSON because comments are useful in code, and JSON is code . For example, I migh…
> and JSON is code
JSON is data. It appears to be JS code, but JSON is data. Data is not code ( http://www.c2.com/cgi-bin/wiki?DataAndCodeAreNotTheSameThing ). That's why the idea of data holding parsing directives is silly. If you want to do that, then embed that in the data (hold a MsgType key in the data records). There's no need for comments unless you are trying to use it for something other than raw data.
Re: Comments in JSON
#94Instead of using tricks that rely on parser implementation behaviors, why not just put an actual comment field in the object? { "myvalue_comment": "This is a comment", "myvalue": 42 }
That example is fine, but you wouldn't want a long comment getting loaded into memory because the parser doesn't know any better.
Re: Comments in JSON
#95Earlier quoted context omitted.
Crockford's rationale for not supporting comments is that people use them to add meta data to the object (e.g. type annotations) which makes it hard to consume with different parsers.
Trusting the community to do the right thing is better than handicapping your users. Regardless, of course, people add metadata to JSON already - there's zero reason you can't "_type": "int". It's a completely arbitrary reason.
JSON did support comments for a time and people were starting to use it for meta data.
The problem is that JSON is not meant to be used a configuration file format and just because it's really good for information exchange, doesn't mean it's good for configuration (and vice-versa). Configuration really requires comment support and information-exchange is better avoiding it. Two standards are needed.
Re: Comments in JSON
#96Instead of using tricks that rely on parser implementation behaviors, why not just put an actual comment field in the object? { "myvalue_comment": "This is a comment", "myvalue": 42 }
That example is fine, but you wouldn't want a long comment getting loaded into memory because the parser doesn't know any better.
Why not? It's just a configuration file.
Re: Comments in JSON
#97There is a interview with the inventor of JSON somewhere. In that interview he explained why he did not allow comments in JSON like in XML. He said - if I remember correctly - that it was intentional to not have comments in JSON. The reason way that comments could be misused to add additional information for a parser. For example in XML you could use comments and a special parser could use these comments to create co…
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability." -- Crockford This is horrific design reasoning. It's an authoritarian, presumptuous, "punish everyone in the classroom because one child misbehaves" mentality. Comments would be useful in JSON because comments are useful in code, and JSON is code . For example, I migh…
So is all opinionated design "stupid"?
I do not presume to know who you are, or what you have accomplished, but there are few people with the professional and academic background that qualify to be able to call Douglas Crockford "stupid".
Re: Comments in JSON
#98Earlier quoted context omitted.
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability." -- Crockford This is horrific design reasoning. It's an authoritarian, presumptuous, "punish everyone in the classroom because one child misbehaves" mentality. Comments would be useful in JSON because comments are useful in code, and JSON is code . For example, I migh…
> and JSON is code JSON is data. It appears to be JS code, but JSON is data. Data is not code ( http://www.c2.com/cgi-bin/wiki?DataAndCodeAreNotTheSameThing ). That's why the idea of data holding parsing directives is silly. If you want to do that, then embed that in the data (hold a MsgType key in the data records). There's no need for comments unless you are trying to use it for something other than raw data.
Nonsense. This is just more arrogance.
JSON is code because I use it as code. It's not your business to tell me it's not code -- you haven't seen how I'm using it. And don't go chirping that I should only do things your way, it's none of your god damned business what I'm using it for.
Further, if JSON was really only data, then it's an incredibly stupid way to store data, given that it has a human-readable syntax that the computer can only deal with after it's been parsed. As data, it's bloated and inefficient. To the extent that JSON is a good format, it's code. To the extent that it's data, it's not a good format.
Re: Comments in JSON
#99Earlier quoted context omitted.
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability." -- Crockford This is horrific design reasoning. It's an authoritarian, presumptuous, "punish everyone in the classroom because one child misbehaves" mentality. Comments would be useful in JSON because comments are useful in code, and JSON is code . For example, I migh…
So is all opinionated design "stupid"? I do not presume to know who you are, or what you have accomplished, but there are few people with the professional and academic background that qualify to be able to call Douglas Crockford "stupid".
Don't put words in my mouth, I didn't claim he was "stupid." To say that one thing he said somewhere is stupidity is a far cry from claiming he is stupid.
I also never said that "opinionated design is stupid".
Perhaps you could rephrase your question in such a way that you aren't presuming to speak for me.
Re: Comments in JSON
#100I'm sure there are counter points to what I'm about to bring up, but three observations: 1. In my experience JSON is frequently output programmatically, and taken in programmatically. Comments are not useful in these cases. 2. The only time comments could be perceived as useful then would be when parsing JSON by eye or hand. However, it is not difficult to parse JSON and understand it unless the keys have used obfusc…
> There is no guarantee that a JSON parser will give you the right value if there are two of the same keys in the same scope. In fact, reading the RFC: > The names within an object SHOULD be unique. I'm pretty sure an implementation could refuse to parse the form altogether.
SHOULD is a horrible word to put in any spec if it doesn't specify what the result will be if that recommendation is violated