4 ms·

The downside of this is that the comment becomes just another piece of the data model, because anything that consumes that JSON will need to decide: do I preser

The downside of this is that the comment becomes just another piece of the data model, because anything that consumes that JSON will need to decide: do I preserve comments, or remove them, when re-emitting the JSON? If I remove them, comments are kind of only useful for things like initial config files or what have you. Which might be fine for your use case, but JSON broadly is not about making configuration files - this is more suited for something like YAML. If you preserve them - how is that different from a key-value just named "comment": "Here's my comment"? (And if the answer is "because it might not crash poorly coded applications," that's more of a discussion about the application than it is about comments in JSON)

vageli 7y ago
Often times people add comments in-line with things to prevent the comment from becoming stale should the referent change (because the inlining encourages modifying the comment if the referent is modified), whereas it may be hard to determine the referent of a comment in its own field. Further, having multiple comments with the same field name is invalid JSON I believe, as keys must be unique? Though I may be wrong. (however, if keys _must_ be unique, then comment authors could encode the referent in the comment key, possibly).
bmm6o 7y ago
>If I remove them, comments are kind of only useful for things like initial config files or what have you.* True, but that's a pretty big use case to dismiss with "only". I don't think people want their json api responses to be able to include comments, but it's definitely convenient to be able to comment out parts of a config file. How/if to expose that through the deserializer is an interesting question, it would be fine with me if it dropped them.
quantified 7y ago
Consider the comment as like a header in HTTP in relation to body content: a side channel for information. I despair that anyone was putting processing pragmas in comments, but you can’t beat all the human out of a programmer. The word “Notation” in JSON and the fact that JSON allows an arbitrary quantity of ignored bytes in any object (whitespace) imply that comments would have been just fine. How many JSON processors are required to preserve whitespace? (Ignorant here, I’ll take any informed answer and learn from it.)

vageli 7y ago

Often times people add comments in-line with things to prevent the comment from becoming stale should the referent change (because the inlining encourages modifying the comment if the referent is modified), whereas it may be hard to determine the referent of a comment in its own field. Further, having multiple comments with the same field name is invalid JSON I believe, as keys must be unique? Though I may be wrong. (however, if keys _must_ be unique, then comment authors could encode the referent in the comment key, possibly).

bmm6o 7y ago

>If I remove them, comments are kind of only useful for things like initial config files or what have you.* True, but that's a pretty big use case to dismiss with "only". I don't think people want their json api responses to be able to include comments, but it's definitely convenient to be able to comment out parts of a config file. How/if to expose that through the deserializer is an interesting question, it would be fine with me if it dropped them.

quantified 7y ago

Consider the comment as like a header in HTTP in relation to body content: a side channel for information. I despair that anyone was putting processing pragmas in comments, but you can’t beat all the human out of a programmer. The word “Notation” in JSON and the fact that JSON allows an arbitrary quantity of ignored bytes in any object (whitespace) imply that comments would have been just fine. How many JSON processors are required to preserve whitespace? (Ignorant here, I’ll take any informed answer and learn from it.)