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

141–150 of 180 posts

Re: Comments in JSON

#141

Post by sixbrx »

nonchalance wrote: post #115
nmcfarl wrote: post #101

Earlier quoted context omitted.

> There's no need for comments unless you are trying to use it for something other than raw data. Is this a true statement? Even books have margins, and word docs comments. I think it’s not infrequent that pure data calls for metadata to put it into context for future users of that data. And in computing most "pure data" formats have had either comments - or schemas and specifications which outline which the contents…

You can represent annotations (which describe most of your examples) by adding keys: { "data": "some data", "data_comments": "here are my comments" }

Not transparent to actual clients of the data.

edit for clarity: You're assuming that the application code isn't doing something with each key that it reflectively sees in the object, e.g. creating database fields to match them, or launching missiles towards those destinations, etc.. If you wouldn't automatically add dummy elements to a hashmap or dictionary in Java or Python, then you shouldn't add keys in a javascript object, unless you control the source to the program that will processing the data. Even then you shouldn't, because it will become a habit to add comments this way, and that will bite you when an extra key does matter.

Re: Comments in JSON

#142

Post by CanSpice »

Given the RFC says "The names within an object SHOULD be unique", there's nothing stopping me from writing a parser that takes the first name/value pair and throwing all the others on the floor. Or even better, picks a random name/value pair when the same name appears. Both of these behaviours are allowed by the RFC, and would break this hack.

Putting comments into JSON in this way is a hack and shouldn't be used by anybody who has any interest in writing maintainable software. Relying on ambiguities in an RFC and someone saying "JSON parsers work the same way" is a good way to end up with a really obscure bug in the future.

Re: Comments in JSON

#143

Post by stormbrew »

ianburrell wrote: post #123
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…

In my experience, YAML is better for configuration files and human edited files. JSON is better for data and communication between computers. The features that make YAML easier to write (comments, more flexible format, less quoting) make it more complex and slower to parse. Also, many of the security holes in YAML come from its use as a serialization format which can represent native classes. I wish the YAML parsers…

Ironically, YAML has object serialization features out the wazoo and JSON for that purpose is relatively more spartan. I will never understand why that happened the way around it did. YAML should have been left at human readable with none of the object serialization stuff thrown in.

Re: Comments in JSON

#144

Post by IanCal »

fusiongyro wrote: post #133
IanCal wrote: post #125

Earlier quoted context omitted.

> It's an authoritarian ... Which is pretty much what a specification is . It's one or more people saying "This is how things are if you call them X". > presumptuous Presumptuous? It was in response to the feature being abused! > "punish everyone in the classroom because one child misbehaves" mentality No more than creating laws is. A significant subset of the population are misusing it in such a way as could cause w…

I'm curious how the notion of XML processing instructions informs your opinion. In general I think having a standard is somewhat more important than the precise details in the standard, but XML PIs enable precisely the kind of thing Crockford feared, yet it doesn't seem to have materialized. Is this because processing instructions are not inherently harmful or because segregating them from comments disarms them?

XML PIs have a spec, don't they? (actual question) From some googling the W3C site has this :

> PIs are not part of the document's character data, but must be passed through to the application

If they're being passed through and not being used by the parser, it's no different really than a

    "directive" : "blah"
in JSON, which is fine. The application at the end needs to deal with it, but the parser doesn't, and that's really important. If it's just a comment, passing the file into and out of a program could remove the comment.

    something.json | python -mjson.tool | myjsonprocessingapp
Should be the same as

    something.json | myjsonprocessingapp
If the parser does need to understand the directive, at least there's a difference between an error of "I don't understand directive X" and no error at all because your parser ignored the comments.

Re: Comments in JSON

#145

Post by tonyg »

juandopazo wrote: post #60
nonchalance wrote: post #5

The JSON RFC ( http://www.ietf.org/rfc/rfc4627.txt?number=4627 ) says The names within an object SHOULD be unique. SHOULD is defined ( http://www.ietf.org/rfc/rfc2119 ) as 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different cou…

And the big point here is that the members of the RFC group were considering breaking the EcmaScript standard and change it to MUST which would break existing programs and the "workaround" in the article.

I wish they had! I wonder why they didn't? JSON is already a subset; limiting it to non-duplicated keys would just tighten it a little.

Re: Comments in JSON

#146

Post by sixbrx »

IanCal wrote: post #26
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…

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

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

Re: Comments in JSON

#147

Post by sixbrx »

njharman wrote: post #111
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…

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

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.

Re: Comments in JSON

#148

Post by dnautics »

IanCal wrote: post #136
dnautics wrote: post #104

Earlier quoted context omitted.

for that matter, just do: { "comment":"this is a comment"; "value": 45; "comment":"this is also a comment"; "value2": 64; "comment":"we like overloading the comment field"; "stringval":"but these stay the same"; }

Then the parser might fail, and rightly so. A comment lower down shows it failing in a simple parser in go: https://news.ycombinator.com/item?id=6147478 Keys SHOULD be unique.

SHOULD != SHALL

And, no, this scheme doesn't break the go parser because there isn't a typeshift between the "comment" fields, they are all strings.

http://play.golang.org/p/bxcIIyAeph

Re: Comments in JSON

#149

Post by TeMPOraL »

nonchalance wrote: post #116
njharman wrote: post #107

Earlier quoted context omitted.

Don't Lisp much do you? Code is data and vice versa. Look up what the acronym JSON means sometime.

Code is data but data isn't necessarily code. Even in Lisp.

The difference is one of interpretation, not of representation; i.e. it's determined by an application, above parser level. When looking just at the written down form, data and code are the same thing.

Code more Lisp and read more Hofstadter ;).

Re: Comments in JSON

#150

Post by TeMPOraL »

defen wrote: post #130
wissler wrote: post #98

Earlier quoted context omitted.

Nonsense. This is just more arrogance. JSON is code because I use it as code. It's not your business to tell me it's not code -- you haven't seen how I'm using it . And don't go chirping that I should only do things your way, it's none of your god damned business what I'm using it for. Further, if JSON was really only data, then it's an incredibly stupid way to store data, given that it has a human-readable syntax th…

> JSON is code because I use it as code You can't use JSON to compute things, therefore it is not code (unless you are willing to concede that any document format is code).

> unless you are willing to concede that any document format is code

Because it is. Data vs. code distinction is arbitrary. The following sequence of characters:

"echo 'foobar';"

can be interpreted as describing a string, a series of tokens, a piece of code, a piece of music or a small icon, whatever interpretation you choose.

Post reply on HN