4 ms·
Nope, because that is still completely valid JSON. Sure it's kind of a shitty choice of structure, but every JSON parser on the planet will be able to read it s
by BillinghamJ 9y ago
Nope, because that is still completely valid JSON. Sure it's kind of a shitty choice of structure, but every JSON parser on the planet will be able to read it successfully.
If you choose to layer some extra logic/rules on top of the actual parsing, that's fine - that would be entirely within the intended purpose of JSON.
Comments are FAR more likely to be used more like "preprocessor directives" to influence actual parsing rules, changing the syntax. Whereas your example conforms perfectly to the syntax, leaving parsing as-is and ensuring the logic is handled at a higher level.
- xg15 9y agoBut if you're already changing the syntax, why do you worry about JSON interop at all? Just invent your own language. If you do worry about JSON interop, then JSON-with-parsing-directives-disguised-as-comments would be valid JSON as well - just treat the directives as comments and ignore them. The resulting tree would probably not reflect the data that the author ment to encode (because you ignored the directives) - but neither would the tree from the example above.
- mseebach 9y agoIt seems a bit like a baby-and-bathwater situation, honestly. It seems feasible to put in the standard something like that comments must be stripped out in the first pass and may never influence the interpretation of the non-commented JSON. A parser-implementation might choose to ignore that, but then it wouldn't be a standards-compliant JSON parser, in the same way it wouldn't be if it brazenly ignored any of the other sections of the standard.
- foobarchu 9y agoYou could, but it probably would be ignored. He was completely justified in making his decision, since the exact problem was worried about is rife in XML.