[avolcano]

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.

[IanCal]

> 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]

How do you know application programs won't barf if they see an unexpected key?

[sehrope]

Or 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

[RHSeeger]

YAML is not a superset of JSON, it's a totally different format.

[TomasSedovic]

According 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

If I understand it correctly, the earlier versions were close but not 100% compatible.

[sehrope]

YAML 1.2 is a super set of JSON. Check out the spec itself: http://www.yaml.org/spec/1.2/spec.html#id2759572

[bct]

It's both.

[phpnode]

Crockford'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]

Trusting 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.

[IanCal]

> 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]

"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]

JSON 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.

[phpnode]

right - 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]

If 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]

That 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]

Yes I get that. What I don't get is how "_processing_instruction": "whatever" is any different.

[masklinn]

And worse than metadata, processing instructions.

[roryokane]

Sublime 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]

Ah, thanks for the correction :)

[njharman]

> 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]

I actually like xml about as much as anything else for complicated config files. I find the explicit (named) block closing tags to help readability.

[d0mine]

  s/^#.*//g

or

  yaml.safe_load(json_file_with_comments)

[xsace]

you can comment things out in sublime text configuration files