This would completely break any event driven (streaming) parser.
Or a parser that simply discards existing keys.
Which, importantly, would be perfectly fine according to the spec (as I understand it).
Comments in JSON
41–50 of 180 posts
Re: Comments in JSON
#42I'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 obfusc…
> 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.
In fact, reading the RFC:
> The names within an object SHOULD be unique.
I'm pretty sure an implementation could refuse to parse the form altogether.
Re: Comments in JSON
#43Earlier quoted context omitted.
Or a parser that simply discards existing keys.
Which, importantly, would be perfectly fine according to the spec (as I understand it).
Indeed, the spec states that keys SHOULD be unique (with RFC 2119 meaning) and leaves behavior unspecified in case of duplicate key.
Re: Comments in JSON
#44It is a 'hack' as discussed in the article and I will probably never use it. JSON should be either self explanatory or documented, I don't see any reason why you would add this unnecessary clutter to these messages.
It is already hard to read as is and it's making it worse to read and confusing, if some big service would start using this, you would have to know about this 'hack' otherwise he would have to look up what the hell is going on.
Also, this is the same information for each call and thus redundant, makes your messages larger when an advantage of JSON is that it's generally a small message.
Re: Comments in JSON
#45This 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…
I used some YAML to configure internal systems, and the impression of my teammates was that it was a bit fragile. Maybe we were using it wrong?
Re: Comments in JSON
#46This 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…
YAML is neat, but library developers have a history of writing unsafe YAML parsers.
There's the famous Rails vulnerability due to YAML. Python needed to add 'yaml.safe_load'.
YAML is a little too rich. It's always one poorly thought out convenience feature away from disaster.
Re: Comments in JSON
#47Earlier quoted context omitted.
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.
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.
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?
Re: Comments in JSON
#48This sounds great until some parser uses the comment definition instead of the value. Is it defined in the spec that parsers need to use the last defined value for a key?
About as defined as anything else in JSON, eg. the range of integers.
Re: Comments in JSON
#49My 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.
Both are only "correct" for specific implementation, this is not specified behavior (and duplicate keys is strongly recommended against by the key)
Re: Comments in JSON
#50This would completely break any event driven (streaming) parser.
Or a parser that simply discards existing keys.
It's overwriting existing keys, which is fine imo. When I use a map in any language and put a new value with a new key, expected behavior is that the previous key is overwritten.