|
|
|
|
|
by lolinder
554 days ago
|
|
> It’s better than having to deal with the ad hoc out-of-band data formats that people would inevitably have stuffed into comments if given the opportunity. As has been pointed out multiple times in the thread so far, a random string that is ignored by the receiver is semantically equivalent to a comment, and people totally stuff random crap into strings to extend the data format in sometimes-horrifying ways. Banning comments doesn't stop us from abusing strings, it just means we don't have a good way to indicate that a part of the file should be ignored by the parser because it's not actually data. |
|
Abusing the string is the correct place to put poorly planned data because it's just data and it has a stable position in the data (and syntax) tree.
But consider this example:
What does the code look like that has to reconcile the directive with the data it modifies?That's a completely different and worse problem than someone "abusing a string" with something like `{ "a": "42 directive" }`.
I think JSON made the right call. People just confuse that with it being somehow forbidden to use comments in JSON config, but they're wrong. Just look at VSCode's config. It was possible all along despite decades of people whining in blogs.
We didn't need comments in JSON over the wire. We didn't need a new format. We didn't need another blog post about it. Just write your tool to accept comments in its config.