4 ms·

The reason why comments aren't allowed anymore in the spec: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCroc

The reason why comments aren't allowed anymore in the spec: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG... And a conversation about it: https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149

coldtea 9y ago
>The reason why comments aren't allowed anymore in the spec Is BS.
- kroltan 9y ago
  Exactly. { "__directive__": "phpstyle_stringly_typed", "boolean": "true" }
  - 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 ago
      But 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 ago
      It 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 ago
        You 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.
  - coldtea 9y ago
    What's that supposed to prove? First, I didn't say it can't happen. Just that it's a BS concern to be worried about in the spec. For one, this thing he is worried can already happen without comments -- just needs a second pass after the parser (or of the parser). Second, this can already happen without comments and a single pass parsing -- just needs out of band parsing instructions. Those needing special parsing pragmas can get them anyway. And the same problem didn't emerge in lots of other formats that allow comments.
  - IshKebab 9y ago
    No that is fine because there is no hidden information that standard JSON tools and libraries cannot access. It's including information in comments - which are meant to be ignored - that is the problem.
- IshKebab 9y ago
  Seems like a good reason to me.

coldtea 9y ago

>The reason why comments aren't allowed anymore in the spec Is BS.

kroltan 9y ago
Exactly. { "__directive__": "phpstyle_stringly_typed", "boolean": "true" }
- 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 ago
    But 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 ago
    It 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 ago
      You 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.
- coldtea 9y ago
  What's that supposed to prove? First, I didn't say it can't happen. Just that it's a BS concern to be worried about in the spec. For one, this thing he is worried can already happen without comments -- just needs a second pass after the parser (or of the parser). Second, this can already happen without comments and a single pass parsing -- just needs out of band parsing instructions. Those needing special parsing pragmas can get them anyway. And the same problem didn't emerge in lots of other formats that allow comments.
- IshKebab 9y ago
  No that is fine because there is no hidden information that standard JSON tools and libraries cannot access. It's including information in comments - which are meant to be ignored - that is the problem.
IshKebab 9y ago
Seems like a good reason to me.