JSON with Commas and Comments
nigeltao.github.io
JSON with Commas and Comments
1–10 of 251 posts
Re: JSON with Commas and Comments
#2> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human-editable configuration files), we might as well have a standard one.
The text "deliberately removed comments from JSON" links to https://web.archive.org/web/20150105080225if_/https://plus.g... where Doug not only explains the reason, but also a solution which works with the existing standard. It's imperative that the JWCC author explain what they find lacking in Doug's solution - stripping comments before handing off the a JSON parser. A new format is a really weird way to go about fixing a problem that already has a solution.
Re: JSON with Commas and Comments
#3Here's another flavour of JSON with comments: https://pypi.org/project/commentjson/
Re: JSON with Commas and Comments
#4> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human-editable configuration files), we might as well have a standard one. The text "deliberately removed comments from JSON" links to https://web.archive.org/web/20150105080225if_/https://plus.g... where Doug not only explains the reason, but also a solution which…
> a practice which would have destroyed interoperability
A baseless reason is not a compelling reason. Some imagined eventual use is not relevant to the utility and convenience. Interoperability (in this greater undefined sense posited) cannot be maintained via syntax anyway.
> stripping comments before handing off the a JSON parser.
Putting an extra processing step before use of JSON is impractical.
Re: JSON with Commas and Comments
#5> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human-editable configuration files), we might as well have a standard one. The text "deliberately removed comments from JSON" links to https://web.archive.org/web/20150105080225if_/https://plus.g... where Doug not only explains the reason, but also a solution which…
> a practice which would have destroyed interoperability A baseless reason is not a compelling reason. Some imagined eventual use is not relevant to the utility and convenience. Interoperability (in this greater undefined sense posited) cannot be maintained via syntax anyway. > stripping comments before handing off the a JSON parser. Putting an extra processing step before use of JSON is impractical.
The base is the part right before that.
> I removed comments from JSON because I saw people were using them to hold parsing directives
> Putting an extra processing step before use of JSON is impractical.
Care to explain?
Re: JSON with Commas and Comments
#6Earlier quoted context omitted.
> a practice which would have destroyed interoperability A baseless reason is not a compelling reason. Some imagined eventual use is not relevant to the utility and convenience. Interoperability (in this greater undefined sense posited) cannot be maintained via syntax anyway. > stripping comments before handing off the a JSON parser. Putting an extra processing step before use of JSON is impractical.
The base is the part right before that. > I removed comments from JSON because I saw people were using them to hold parsing directives > Putting an extra processing step before use of JSON is impractical. Care to explain?
People want to use JSON as on disk configuration files, and that's where they want the comments and trailing commas. You can either generate the configuration file from another file, which is frankly stupid annoying and leads to repositories with two copies of the same information, or modify the software that reads the configuration file to strip it before handing it to the JSON parser... which clearly "solves the problem" but also begs the question "ok, so what is the format of the actual confirmation file, then?". The answer to that latter question is more important, as the goal would then be to get everyone to standardize around that format, at which point (I guess) "JSON" would be obsolete as no one would use it and everyone would be using the new JSON wrapper format and all implementations would be designed to have a way to read that format... but like, at that point, you are just making a weird semantics argument. I think the core problem is we just have too many of these... like, what happened to JSON5? We need some reason to all rally around a single specific format of "JSON, but with comments and trailing commas (and I will personally request multi-line strings)".
Re: JSON with Commas and Comments
#7> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human-editable configuration files), we might as well have a standard one. The text "deliberately removed comments from JSON" links to https://web.archive.org/web/20150105080225if_/https://plus.g... where Doug not only explains the reason, but also a solution which…
Crockford regularly displays a stunning degree of tunnel vision.
Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc comments in a JSON file made by anyone who isn't you to be styled like JavaScript comments. And if your response is "then everyone needs to use JavaScript-style comments", well, TA-DA, you've just added comments to the spec. You can't have it both ways.
> It's imperative that the JWCC author explain what they find lacking in Doug's solution - stripping comments before handing off the a JSON parser
If the syntax rules for adding comments are unspecified, then the the syntax rules for what to strip out are unspecified too!
Re: JSON with Commas and Comments
#8Earlier quoted context omitted.
> a practice which would have destroyed interoperability A baseless reason is not a compelling reason. Some imagined eventual use is not relevant to the utility and convenience. Interoperability (in this greater undefined sense posited) cannot be maintained via syntax anyway. > stripping comments before handing off the a JSON parser. Putting an extra processing step before use of JSON is impractical.
The base is the part right before that. > I removed comments from JSON because I saw people were using them to hold parsing directives > Putting an extra processing step before use of JSON is impractical. Care to explain?
> I removed comments from JSON because I saw people were using them to hold parsing directives
Java has not been destroyed, nor any other language that uses injected behavior. Ironically, applying parsing directives are basically another tool being run (similar to a linter) so I'm not sure what he's even getting at when suggesting running yet another tool. This just complicates the ecosystem and is part of what makes javascript seem so primitive in use and syntax. Features that are counterproductive for poorly considered reasons.
Re: JSON with Commas and Comments
#9> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human-editable configuration files), we might as well have a standard one. The text "deliberately removed comments from JSON" links to https://web.archive.org/web/20150105080225if_/https://plus.g... where Doug not only explains the reason, but also a solution which…
If I’m going to use “JSON with comments” that I have to run through a preprocessor before parsing, why not just use a language where comments are explicitly allowed (YAML, TOML, etc.)? Crockford’s answer is not a solution. His words can be rewritten as: “you want comments? Use a different language that looks and feels like JSON, but isn’t.” All that does is add confusion.
The only reason JSON is as popular as it is is because JavaScript parses it natively (JSON.parse is defined by the JS spec).
Re: JSON with Commas and Comments
#10Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. Most parsers support various flags already to configure things, so there could just be an ALLOW_COMMENTS flag and ALLOW_TRAILING_COMMAS flag.
As a case in point, the python parser breaks the JSON spec already with regards to Infinity/NaN, but then has flags to configure this. See https://docs.python.org/3/library/json.html#module-json
> The RFC does not permit the representation of infinite or NaN number values. Despite that, by default, this module accepts and outputs Infinity, -Infinity, and NaN as if they were valid JSON number literal values: