I'd be happy about a JSON spec that allows for comments...
I'll probably never not have to manually edit JSON, so JSON's insistence that using the same format for your final line as for all the others won't ever be allowed will remain a never ending, unnecessary nuisance in the spirit of JavaScript itself: the "too bad, too late now" school of design. Except that in this case, even JavaScript corrected that particular nuisance and allows trailing commas.
But who knows, maybe that is what was needed at the time to make JSON popular.
{
"file": "/etc/foo",
"daemon": true
}
{
"file": "/etc/foo",
"_daemon_comment": "default is false",
"daemon": true
}Because Douglas Crockford didn't want people abusing comments in JSON by turning them into parsing directives, JSON doesn't allow using comments at all, even correctly, so everyone is left abusing JSON itself with workarounds that are objectively worse than just having comments.
https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
And a conversation about it:
Is BS.
{
"__directive__": "phpstyle_stringly_typed",
"boolean": "true"
}If you choose to layer some extra logic/rules on top of the actual parsing, that's fine - that would be entirely within the intended purpose of JSON.
Comments are FAR more likely to be used more like "preprocessor directives" to influence actual parsing rules, changing the syntax. Whereas your example conforms perfectly to the syntax, leaving parsing as-is and ensuring the logic is handled at a higher level.
If you do worry about JSON interop, then JSON-with-parsing-directives-disguised-as-comments would be valid JSON as well - just treat the directives as comments and ignore them.
The resulting tree would probably not reflect the data that the author ment to encode (because you ignored the directives) - but neither would the tree from the example above.
First, I didn't say it can't happen. Just that it's a BS concern to be worried about in the spec.
For one, this thing he is worried can already happen without comments -- just needs a second pass after the parser (or of the parser).
Second, this can already happen without comments and a single pass parsing -- just needs out of band parsing instructions.
Those needing special parsing pragmas can get them anyway.
And the same problem didn't emerge in lots of other formats that allow comments.
https://github.com/tlocke/zish
(as the author, I'm biased)
I'd rather only /* */ comments were allowed. By allowing //, you've now got two varieties of white-space the parser needs to be aware of. Because of this, I can't take multiple lines of ZISH and join them together into a single line. (Something both JSON and XML can do.)
What is a "line"? CR, LF, CRLF, LFCR, FF, VT, U+0085, U+2028, U+2029?
Am I required to treat ZISH files as "binary"? Could I convert all of those end-of-line bytes into my OS's preferred form without losing data?
The notation of ending a line with a \ also prevents joining multiple lines into a single line. Maybe formalize "string"+"string" as an explicit string joining notation? (Or if not +, some other character to notate string concatenation.)
Given you have the decimal type, is float necessary? Values with a "e" are still expressed with decimal digits.
Is there a limit to numeric types? What if my ZISH file contained a several hundred 9s in a row?
Sets seems unnecessary given you already have lists. You can take a list and treat it as a set after parsing with no loss of data.
I very much like the addition of timestamps and binary without needing a string. This is my big pet peeve of JSON.
Your examples include uses of null and true, but your spec doesn't define those values. (Or false for that matter.)
The description of map doesn't specify if the order of keys is significant. Is {"a":"b", "c":"d"} the same as {"c":"d", "a":"b"} ?
The only place I'd like to have comments is in configuration files and in that case there are less verbose formats that do allow for comments.
TOML is tolerable, but all my preferred languages already have JSON parsers I'm familiar with, but while they may have TOML parsers, I'd have to go looking for onne.
Config isn't meant to be code, and config files shouldn't be updated often, so a config file format doesn't need a great deal of expressiveness. Dealing with quoting keys and commas in JSON isn't more or less of a hassle than dealing with significant whitespace or whatever pecadillos those other formats have.
Although personally I really like Lua tables for config because they have an even simpler structure than JSON and you can add comments. I have to resist the tempation to turn Lua config files into applications, though.
JSON doesnt care as long as it's valid, and there are parsers for every language and environment.
If the parsers do something different, that's an implementation issue, which inevitably affects all formats. This affects json as well: http://seriot.ch/parsing_json.php
I had to diff on-wire JSON payloads to find a discrepancy, and boy was it a pain, whereas having those trailing commas would have reduced the diff to a quite direct and obvious pointer to the faulty change.
I like it more than any other config format, really.
{
a: 5
}
I personally dislike it the most when you want to provide a commented example of your data format, vanilla JSON won't allow you to do that.