4 ms·
Can we all just agree, as a community, to add comment support to our JSON parsers? Hell, I'd do a PR on V8 if I knew C++. It's ridiculous that I can't document
by avolcano 13y ago
Can we all just agree, as a community, to add comment support to our JSON parsers? Hell, I'd do a PR on V8 if I knew C++.
It's ridiculous that I can't document notes on dependencies in my NPM package.json, or add a little reminder to my Sublime Text configuration as to why I set some value, because we're using JSON parsers that can't handle the concept of ignoring a line with a couple slashes prefixing it.
IMO - either we add comments to JSON, or we stop using it for hand-edited configuration.
- deleted 13y ago[deleted]
- buro9 13y agoTOML is nice for config files: https://github.com/mojombo/toml https://github.com/mojombo/toml
- phpnode 13y agoCrockford's rationale for not supporting comments is that people use them to add meta data to the object (e.g. type annotations) which makes it hard to consume with different parsers.
- avolcano 13y agoTrusting the community to do the right thing is better than handicapping your users. Regardless, of course, people add metadata to JSON already - there's zero reason you can't "_type": "int". It's a completely arbitrary reason.
- phpnode 13y agoright - but that is valid syntax! any json parser can understand that, and that's what he recommends doing instead. But if you're doing this in comments, you end up writing your own mini language to describe your annotations, and nothing else knows how to parse it. that should clearly be avoided.
- esailija 13y agoIf JSON had comments, then of course any JSON parser could understand those comments just as well as they can currently understand "_type": "int". What am I missing?
- masklinn 13y agoThat because they're comments specific JSON parsers could (and likely would) interpret processing instructions embedded in those comment to toggle behaviors on the fly. Crockford's fear (founded I think) was that comments would be used to "extend" json.
- esailija 13y agoYes I get that. What I don't get is how "_processing_instruction": "whatever" is any different.
- phpnode 13y agowhen you do { "_type": "int", "foo": "123" } a JSON parser will always know how to represent that object. How you process that object is up to you. However, when you write: { // @type int this is a comment "foo": "123" } and you call JSON.parse(), what would you expect to get back? You can no longer represent it as a simple object, you need some way to access the comment, how do you do that? Moreover, whose responsibility is it to process the annotation in that comment? the parser's? Should you get back an integer rather than a string for obj.foo? how would you support different types of annotation? What happens if you're using parser A and your client uses parser B? Does parser B support all the annotations that parser A supports? If you need to modify a JSON structure, e.g. JSON decoding, adding a property and re-encoding, should the comments be preserved? ... You can see that having comments introduces a whole host of other questions, ambiguity and would only make it harder for different platforms to share data. Avoiding this kind of cruft is why JSON is winning vs XML for most things these days.
- 13y ago
- IanCal 13y ago> Regardless, of course, people add metadata to JSON already - there's zero reason you can't "_type": "int" Which is fine, because it's in a format that everyone can parse. Adding //COMMAND: Extension(github:IanCal/preparser).parsethis is the kind of things this forbids. Most peoples parsers would ignore this as a comment (if we have comments), but maybe some would do it in a special way. Either everyone ignores the comments in the parser (this is unlikely to carry on for long, someone will want to extend it) or nobody is allowed comments. That way everyone parses the same text.
- jerf 13y ago"Trusting the community to do the right thing is better than handicapping your users." And the "community" in question had repeatedly and grossly demonstrated itself to be unworthy of such trust. Crockford was not hypothesizing that this might happen, he'd seen it. Repeatedly. If you want to argue against it even so, fine, but bear in mind that is what you are arguing against, real pain that real people experienced, not mere possibilities.
- wvenable 13y agoJSON did support comments for a time and people were starting to use it for meta data. The problem is that JSON is not meant to be used a configuration file format and just because it's really good for information exchange, doesn't mean it's good for configuration (and vice-versa). Configuration really requires comment support and information-exchange is better avoiding it. Two standards are needed.
- masklinn 13y agoAnd worse than metadata, processing instructions.
- d0mine 13y agos/^#.*//g or yaml.safe_load(json_file_with_comments)
- sehrope 13y agoOr just use YAML[1]. It's a super set of JSON, includes comments, nicely formatted lists, and is (IMHO) much easier on the eyes. [1]: http://en.wikipedia.org/wiki/Yaml http://en.wikipedia.org/wiki/Yaml
- RHSeeger 13y agoYAML is not a superset of JSON, it's a totally different format.
- TomasSedovic 13y agoAccording to the spec, YAML 1.2 is: "The primary objective of this revision is to bring YAML into compliance with JSON as an official subset." http://yaml.org/spec/1.2/spec.html http://yaml.org/spec/1.2/spec.html If I understand it correctly, the earlier versions were close but not 100% compatible.
- bct 13y agoIt's both.
- sehrope 13y agoYAML 1.2 is a super set of JSON. Check out the spec itself: http://www.yaml.org/spec/1.2/spec.html#id2759572 http://www.yaml.org/spec/1.2/spec.html#id2759572
- roryokane 13y agoSublime Text actually already supports '//' comments in its "JSON" configuration files, though it's non-standard. The comments are properly ignored, and syntax-highlighted. However, the comments (along with all other manual formatting) are lost if the file is programmatically edited, for example by changing the font size using the keyboard shortcuts.
- avolcano 13y agoAh, thanks for the correction :)
- IanCal 13y ago> It's ridiculous that I can't document notes on dependencies in my NPM package.json, or add a little reminder to my Sublime Text configuration as to why I set some value Why not have { "keyname" : "aldkjfhaldhfa" "keyname_comment" : "asdfjnad" } If that's not enough, use something other than JSON. Adding comments will just result in it being valid in some parsers and not others.
- sixbrx 13y agoHow do you know application programs won't barf if they see an unexpected key?
- xsace 13y agoyou can comment things out in sublime text configuration files
- njharman 13y ago> we stop using it for hand-edited configuration. Bing, Bing, Bing. We have a winnar!!! XML sucks in large part not because of XML but because people used it for everything, everywhere in places it was highly ill-suited. Don't fuckup JSON the same way.
- sixbrx 13y agoI actually like xml about as much as anything else for complicated config files. I find the explicit (named) block closing tags to help readability.