And for a data interchange format this is also 100% reasonable.
The problem is that people have started using JSON for configuration files and the like, which IMHO has always been – and continues to be – the wrong tool for the job.
How does that relate? Your config parser can disregard commments.
Yes, but JSON was never intended for that use case – the feature set isn't geared towards it.
Re:SQLite Release 3.42.0
by mikepurvis on Tuesday May 16, 2023 @11:53AM
(#35963568)
I think the point is that your config parser should be using yaml or toml, though in fairness neither of those existed in the early 2000s when JSON was being developed/discovered/adopted— the 800lb gorilla in that space at the time was XML.
And XML remained dominant for a long time— for example, the original Google Maps from 2005 received its server responses as XML blobs, and API v2 even exposed the relevant parsing functionality as the GXml JavaScript class. By around 2007, it was all JSONp I think, and GXml was deprecated and removed in API v3 and v4 respectively.
What comments? JSON doesn't have any.
And editor will rightfully mark them as errors.
Re:SQLite Release 3.42.0
by anentropic on Tuesday May 16, 2023 @12:07PM
(#35963829)
that's the JSON5 support
That's my point. Parent says that config parser can disregard comments. Why would it need to disregard comments if it was json5?
Let's add parsing directives then.
> Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
Every problem can be solved by introducing a build step, except for the problem of having too many build steps.
Re:SQLite Release 3.42.0
by Dylan16807 on Wednesday May 17, 2023 @01:41AM
(#35971647)
That was never a very realistic worry, especially because you can do the same thing without comments.
We can now have different parsers have pragmas that specify different behaviour depending on whether those pragmas are recognized or not.
In case anyone was wondering, the history is that comments were considered an anti-feature by Douglas Crockford, the creator of JSON:
> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.
> Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
* https://web.archive.org/web/20150105080225/https://plus.goog...
* https://en.wikipedia.org/wiki/Douglas_Crockford