Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comments in JSON

fadefade.com

Post reply on HN
Print view View original

61–70 of 180 posts

Re: Comments in JSON

#61

Post by ygra »

wmil wrote: post #46
NathanKP wrote: post #23

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

And JSON was often “parsed” with eval().

Re: Comments in JSON

#63

Post by esailija »

masklinn wrote: post #55
esailija wrote: post #47

Earlier quoted context omitted.

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?

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.

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

Re: Comments in JSON

#64

Post by IanCal »

jfoutz wrote: post #40
jasonlotito wrote: post #13

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

> it's up to the parser to keep clobbering a value every time a new value comes in for a given k

Nope, parsers are perfectly in their rights to do whatever they want with multiple keys. They could read them backwards, sort them, whatever. The behaviour in the instance of multiple keys is undefined.

> This seems like a bad idea.

It is an astonishingly bad idea. I'm concerned by it being so high on the page.

> But hey, might work well for the original author.

Depends on their parser. It's undefined behaviour according to the spec. It might work now, but I'd argue it doesn't work well, as a patch level change could bork this.

Re: Comments in JSON

#65

Post by masklinn »

_ZeD_ wrote: post #59
masklinn wrote: post #49

Earlier quoted context omitted.

Both are only "correct" for specific implementation, this is not specified behavior (and duplicate keys is strongly recommended against by the key)

absolutely. This is nothing more than a clever trick, but I would never rely on it. Honestly, tough, I think all major JSON parser behave following the two assumption.

streaming parsers can't follow the assumption short of becoming useless. They're either going to send only the first instance or going to send two different events.

Re: Comments in JSON

#66

Post by IanCal »

masklinn wrote: post #43
IanCal wrote: post #41

Earlier quoted context omitted.

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.

My favourite example of dealing with undefined behaviour is this:

In practice, many C implementations recognize, for example, #pragma once as a rough equivalent of #include guards — but GCC 1.17, upon finding a #pragma directive, would instead attempt to launch commonly distributed Unix games such as NetHack and Rogue, or start Emacs running a simulation of the Towers of Hanoi.[7]

Source: http://en.wikipedia.org/wiki/Undefined_behavior

Re: Comments in JSON

#67

Post by RHSeeger »

sehrope wrote: post #24
avolcano wrote: post #12

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 - eith…

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

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

Re: Comments in JSON

#68

Post by jerf »

jaredmcateer wrote: post #29
LinaLauneBaer wrote: post #11

There is a interview with the inventor of JSON somewhere. In that interview he explained why he did not allow comments in JSON like in XML. He said - if I remember correctly - that it was intentional to not have comments in JSON. The reason way that comments could be misused to add additional information for a parser. For example in XML you could use comments and a special parser could use these comments to create co…

Yes the JSON spec was designed with interoperability in mind, I don't believe Crockford claims to have invented JSON, merely discovered it. That said if you want your Static JSON objects to have comments, just pipe the JSON object through a minifier to strip comments before parsing.

He both invented and discovered it. Yes, the object literal syntax existed, but he also carefully (and IMHO correctly) specified a strict subset as well, for these interoperability reasons. For instance, Javascript is happy with {a: 1}, but that is not legal JSON. It's a very well done standard.

Re: Comments in JSON

#69

Post by sktrdie »

This is a horrible hack. You should use JSON-LD [1] to describe the fields of your JSON. It's a W3C standard!

Also, it's not defined in the JSON standard in which order an implementation needs to parse the JSON fields/keys. So you could end up with potentially wrong results!

1. http://json-ld.org/

Re: Comments in JSON

#70

Post by k3n »

jmcdonald-ut wrote: post #33

I'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…

Re: #1

I know there is a lot of JSON handling that happens behind-the-scenes, but there is also a non-trivial amount of JSON that I have manually created and/or altered, and have to share with a team.

It's a blessing and a curse, these modern NodeJS projects -- it's awesome that I can simply create/modify a .json file with a few properties, run a command, and magic happens. However, if I want to try and communicate out the intent of the values to my team of 20+, it becomes really convoluted. The projects all magically work by looking for foo.json, but if I comment that file then it breaks.

So I have to create another foo.comments.json, add another script that will remove the comments and then call the original instructions. Then I need to create additional documentation instructing the team to ignore the developer's docs regarding native use, and to run the application with our own homebrew setup.

It also can make testing a pain in the ass, because now I can no longer comment out values, I have to remove them completely. Not a huge deal, annoying nonetheless.

Post reply on HN