131–140 of 180 posts
Earlier quoted context omitted.
You can represent annotations (which describe most of your examples) by adding keys: { "data": "some data", "data_comments": "here are my comments" }
or just use the key "comment" more than once, which is sort of a hybrid of the ideas.
This guy is fast. Especially nice considering we do not know each other at all.
[1] http://www.jslint.com/ - JS checking tool from the inventor of JSON
Earlier quoted context omitted.
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability." -- Crockford This is horrific design reasoning. It's an authoritarian, presumptuous, "punish everyone in the classroom because one child misbehaves" mentality. Comments would be useful in JSON because comments are useful in code, and JSON is code . For example, I migh…
> 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…
Earlier quoted context omitted.
> 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.
SHOULD is a horrible word to put in any spec if it doesn't specify what the result will be if that recommendation is violated
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 course.
All it means is a parser isn't required to reject JSON with multiple keys. It can, however, do whatever the fuck it wants with them.
If the wording was precise, then it should be a MUST. SHOULD indicates a terrible world of unknown consequences.
I do something else that is a lot more readable: { "#": "this is a comment for the next line", "url": "http://foo.bar" } Simple.
Earlier quoted context omitted.
That example is fine, but you wouldn't want a long comment getting loaded into memory because the parser doesn't know any better.
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"; }
Keys SHOULD be unique.
Earlier quoted context omitted.
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability." -- Crockford This is horrific design reasoning. It's an authoritarian, presumptuous, "punish everyone in the classroom because one child misbehaves" mentality. Comments would be useful in JSON because comments are useful in code, and JSON is code . For example, I migh…
So is all opinionated design "stupid"? I do not presume to know who you are, or what you have accomplished, but there are few people with the professional and academic background that qualify to be able to call Douglas Crockford "stupid".
> The reason to use semicolons is because coding rigor tends to produce significantly better software.
Funny story. JSLint[1] does not approve of this technique. I asked Crockford to implement the duplicate check in April 2009 via email. 20 minutes later, out of nowhere, he was done implementing that check and wrote back "Please try it now." This guy is fast. Especially nice considering we do not know each other at all. [1] http://www.jslint.com/ - JS checking tool from the inventor of JSON
He responded that he was getting annoyed by everybody asking for this, so it was going to cost me $100K to obtain such a license.
I responded that I only asked for that license in order to annoy him (and thanks for the confirmation that it worked), because his immature license clause is annoying everybody else.
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.
It has parsers for nearly every language, I wrote one for js: http://npmjs.org/package/tomljs