3 ms·

> The reason never made much sense, anything can be abused (...) I don't think your take makes sense. Comments were purposely left out of JSON to mitigate the

> The reason never made much sense, anything can be abused (...) I don't think your take makes sense. Comments were purposely left out of JSON to mitigate the problem described by Hyrum's law. Smaller interface means a smaller surface to allow abuse. You're just arguing to facilitate abuse because you feel the abuse that was indeed avoided by leaving comments out is unavoidable, which is a self-contradiction. On top of that,think about the problem for a second. Why do you feel it's reasonable to support comments in data interchange formats? This use case literally means wasting bandwidth with data that clients should ignore. The only scenario where clients are not ignoring comments if exactly the scenario that it's being avoided: abusing it for control purposes. If you want a data interchange format to support that, you should really adopt something that is better suited for your whole use case. > and your suggestion doesn't help with eg syntax highlighting tools for your config that will treat comments as syntax errors (...) That's the whole point. This is by design, not a fault. Why are you pretending a language supports a feature it never supported and explicitly was designed to not support?

eviks 2y ago
> Smaller interface means a smaller surface to allow abuse. If you take your law seriously, this is irrelevant because the surface of abuse is on the same scale of practical infinity, so it doesn't matter that one infinity is technically smaller. For example, based of the example in the quote: you could stick those directives from comments info #hashtags in stringy values, with the same effect that there is no interoperable way to parse values (or if you add "_key_comment" - there is no interoperable way to even parse keys as some of them need to be ignored) So the designer has achieved no benefit by removing a valuable feature > abuse that was indeed avoided Nothing was avoided, you can have the exact same abuse tucked into other elements > Why do you feel it's reasonable to support comments in data interchange formats? Why does the author of the quote sees the obvious which you don't see even after reading the quote? Go convince him his comment makes no sense because of "data interchange" Obviously it's not only used for data interchange in cases where every byte matters (reminder: this is a TEXT-based format) and also comments matter to humans working with this data > adopt something that is better suited for your whole use case. And this discussion is literally about a format supports that? But also, how does this in any way mitigate the flaws in the designer's arguments? > Why are you pretending a language supports a feature it never supported and explicitly was designed to not support? Same thing, why is the author of the quote makes this senseless suggestions then? Go convince him first
- motorest 2y ago
  > If you take your law seriously, (...) Hyrum's law is not mine. It's a statement of fact that goes by that name already for a few decades and is noted by anyone who ever worked on production services that exposes an interface and is consumed by third parties. > (...) this is irrelevant because the surface of abuse is on the same scale of practical infinity, so it doesn't matter that one infinity is technically smaller. It really isn't. JSON does not support comments, thus they aren't abused in ways that sabotage interoperability. The only option you have is to support everything at the document schema level. You can't go around it. > For example, based of the example in the quote: you could stick those directives from comments info #hashtags in stringy values, (...) Irrelevant. You're specifying your own schema, not relying in out-of-band information. That's exactly how a data interchange format is designed to be used. There is no way around it. If you understand the problem domain, the fact that leaving out comments is an elegant solution to a whole class of problems is something that's immediately obvious to you.
  - cogman10 2y ago
    The arguments presented here would also lead someone to not use JSON for data interchange. If specifying the schema is important then why not an interchange format with strict schema enforcement like XML? If minimal feature sets to avoid abuse are so important, then why not a binary format like protobufs which also have strict schema dictates? And if interoperability is important then why not ditch REST/JSON all together and instead favor SOAP which strictly defines how interoperability works? That's why I don't buy the "comments might be abused" argument. JSON doesn't have a single problem domain and it's not the only solution in town.

eviks 2y ago

> Smaller interface means a smaller surface to allow abuse. If you take your law seriously, this is irrelevant because the surface of abuse is on the same scale of practical infinity, so it doesn't matter that one infinity is technically smaller. For example, based of the example in the quote: you could stick those directives from comments info #hashtags in stringy values, with the same effect that there is no interoperable way to parse values (or if you add "_key_comment" - there is no interoperable way to even parse keys as some of them need to be ignored) So the designer has achieved no benefit by removing a valuable feature > abuse that was indeed avoided Nothing was avoided, you can have the exact same abuse tucked into other elements > Why do you feel it's reasonable to support comments in data interchange formats? Why does the author of the quote sees the obvious which you don't see even after reading the quote? Go convince him his comment makes no sense because of "data interchange" Obviously it's not only used for data interchange in cases where every byte matters (reminder: this is a TEXT-based format) and also comments matter to humans working with this data > adopt something that is better suited for your whole use case. And this discussion is literally about a format supports that? But also, how does this in any way mitigate the flaws in the designer's arguments? > Why are you pretending a language supports a feature it never supported and explicitly was designed to not support? Same thing, why is the author of the quote makes this senseless suggestions then? Go convince him first

motorest 2y ago
> If you take your law seriously, (...) Hyrum's law is not mine. It's a statement of fact that goes by that name already for a few decades and is noted by anyone who ever worked on production services that exposes an interface and is consumed by third parties. > (...) this is irrelevant because the surface of abuse is on the same scale of practical infinity, so it doesn't matter that one infinity is technically smaller. It really isn't. JSON does not support comments, thus they aren't abused in ways that sabotage interoperability. The only option you have is to support everything at the document schema level. You can't go around it. > For example, based of the example in the quote: you could stick those directives from comments info #hashtags in stringy values, (...) Irrelevant. You're specifying your own schema, not relying in out-of-band information. That's exactly how a data interchange format is designed to be used. There is no way around it. If you understand the problem domain, the fact that leaving out comments is an elegant solution to a whole class of problems is something that's immediately obvious to you.
- cogman10 2y ago
  The arguments presented here would also lead someone to not use JSON for data interchange. If specifying the schema is important then why not an interchange format with strict schema enforcement like XML? If minimal feature sets to avoid abuse are so important, then why not a binary format like protobufs which also have strict schema dictates? And if interoperability is important then why not ditch REST/JSON all together and instead favor SOAP which strictly defines how interoperability works? That's why I don't buy the "comments might be abused" argument. JSON doesn't have a single problem domain and it's not the only solution in town.