You should use standard JS comments and process them out. Douglas Crockford's offical answer on comments, https://plus.google.com/118095276221607585885/posts/RK8qyGVa.... Essentially just process them out beforehand with something like jsmin, pretty straightforward.
Comments in JSON
31–40 of 180 posts
Re: Comments in JSON
#32This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. JSON works great for on the fly communication with frontends that are running JavaScript, or for communication between JavaScript processes like Node.js servers. But for configuration files and other things that need comments YAML is many times better, both for it's clean, Ma…
This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON.
Rails RCE, sup
Re: Comments in JSON
#33I'm sure there are counter points to what I'm about to bring up, but three observations:
1. In my experience JSON is frequently output programmatically, and taken in programmatically. Comments are not useful in these cases.
2. The only time comments could be perceived as useful then would be when parsing JSON by eye or hand. However, it is not difficult to parse JSON and understand it unless the keys have used obfuscated names. If key naming is obfuscated, comments aren't really the correct solution.
3. "An object is an unordered set of name/value pairs", as mentioned by jasonlotito and others earlier. There is no guarantee that a JSON parser will give you the right value if there are two of the same keys in the same scope.
Re: Comments in JSON
#34Can 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 - eith…
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.
Ah, thanks for the correction :)
Re: Comments in JSON
#35This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. JSON works great for on the fly communication with frontends that are running JavaScript, or for communication between JavaScript processes like Node.js servers. But for configuration files and other things that need comments YAML is many times better, both for it's clean, Ma…
This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. Rails RCE, sup
I've actually never developed anything serious in Rails. I just don't like the framework, and the performance of Rails leaves a lot to be desired in my opinion. I'm a 100% Node.js convert these days.
But I do like the Rails convention of using YAML format and have adopted that in my own code as much as possible.
Re: Comments in JSON
#36Can 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 - eith…
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.
And worse than metadata, processing instructions.
Re: Comments in JSON
#37My first thought in seeing this was that objects aren't guaranteed to maintain order: "An object is an unordered set of name/value pairs" - http://www.json.org
while this is true, I think it's irrelevant: the "trick" is about "abusing"
* the fact parser work from top to bottom of the text
AND
* the fact that assigning the same key many times with different values update the key with the last value
your quote regards the order in witch the different keys are saved.
Re: Comments in JSON
#38Earlier quoted context omitted.
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.
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.
> 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
Re: Comments in JSON
#39Note that these comments would disappear the second you use a JSON-aware tool to manipulate one of these files.
You hope it is the comment dupe that disappears and not the field you want.
Re: Comments in JSON
#40My first thought in seeing this was that objects aren't guaranteed to maintain order: "An object is an unordered set of name/value pairs" - http://www.json.org
There is an intrinsic order in the text though. it's up to the parser to keep clobbering a value every time a new value comes in for a given key.
This seems like a bad idea. It seems heavily reliant on edge case behavior. But hey, might work well for the original author.