This is a recipe for disaster.
Comments in JSON
81–90 of 180 posts
Re: Comments in JSON
#82I do something else that is a lot more readable:
{
"#": "this is a comment for the next line",
"url": "http://foo.bar"
}
Re: Comments in JSON
#83Earlier quoted context omitted.
That because they're comments specific JSON parsers could (and likely would) interpret processing instructions embedded in those comment to toggle behaviors on the fly. Crockford's fear (founded I think) was that comments would be used to "extend" json.
Yes I get that. What I don't get is how "_processing_instruction": "whatever" is any different.
when you do
{
"_type": "int",
"foo": "123"
}
However, when you write:
{
// @type int this is a comment
"foo": "123"
}
You can see that having comments introduces a whole host of other questions, ambiguity and would only make it harder for different platforms to share data. Avoiding this kind of cruft is why JSON is winning vs XML for most things these days.
Re: Comments in JSON
#84> Believe it or not, it turns out JSON parsers work the same way
Please don't do this. There's almost certainly some parsers out there currently that don't work like this, and if not, there likely will be one day.
Re: Comments in JSON
#85Terrible spec-violating hack aside, the idea of the author soliciting upvotes on StackOverflow doesn't sit well with me. I'd hate for SO solutions to become diluted by answers from users who are 'marketing' for upvotes.
Re: Comments in JSON
#86Instead 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
}Re: Comments in JSON
#87I'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…
Re: #1 I know there is a lot of JSON handling that happens behind-the-scenes, but there is also a non-trivial amount of JSON that I have manually created and/or altered, and have to share with a team. It's a blessing and a curse, these modern NodeJS projects -- it's awesome that I can simply create/modify a .json file with a few properties, run a command, and magic happens. However, if I want to try and communicate o…
Why not adding an object field with identifier a_comment:"blabla..."
The advantage I see in this way of commenting is that the comment becomes accessible inside the program instead of being stripped off by the parser. For the human reader it's also more obvious.
Unfortunately, it's not possible to add comment to anything else than objects. But the OP's proposal as well.
Re: Comments in JSON
#88This, to me, looks like an example of relying on a nondeterministic implementation. To my knowledge, the standard doesn't prescribe that parsers take the second/last of a duplicate key. As a result, this is relying on implementation-specific choices which can lead to a terrible upgrade process.
Switch to a different JSON parser, does it still work? probably. but I wouldn't bet that much.
If I were implementing a JSON parser, might I throw an error on a duplicate key? maybe. Maybe I would just print a warning?
If I were every going to give someone advice it would be to never do this.
Re: Comments in JSON
#89There 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 might have a config file that I'm typing in that I want to leave a documentation trail for.
Don't tell me I can do a silly thing like redefine a field, as if it's "neat". It's an abomination that I have to resort to such things. And guess what: by resorting to such things I can still do precisely what Crockford claims he was trying to prevent. So his rationale is not only insulting to one's intelligence, it's sheer stupidity.
Re: Comments in JSON
#90Earlier quoted context omitted.
Yes I get that. What I don't get is how "_processing_instruction": "whatever" is any different.
when you do { "_type": "int", "foo": "123" } a JSON parser will always know how to represent that object. How you process that object is up to you. However, when you write: { // @type int this is a comment "foo": "123" } and you call JSON.parse(), what would you expect to get back? You can no longer represent it as a simple object, you need some way to access the comment, how do you do that? Moreover, whose responsib…
In the eyes of compliant parser (assuming JSON supported comments) it is just a comment like "_type": "int" is just a key-value pair.
However, when using ad hoc parser, then all bets are off what the result is in both cases again, not just the comment case. Regardless of comment support in JSON the same problem appears to exist.