4 ms·

{ "//": "I approve of the choice to omit comments from JSON." }

by DTrejo 14y ago

generateui 14y ago
I was exactly thinking this when I was halfway reading the article. "Why not just add a property as comment?"
- Yarnage 14y ago
  Article? It's only 5 short sentences and the idea to add it as a property is the first comment on the post.
  - generateui 14y ago
    Article, blogpost, same thing. The first sentence is > I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I do not read something on the lines of "you can also use a comment as a property". I wonder how you read that in the first sentence?
    - kcbanner 14y ago
      He said first comment, not first sentence.
    - Yarnage 14y ago
      >> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. >I do not read something on the lines of "you can also use a comment as a property". I wonder how you read that in the first sentence? lol, please re-read my comment. I said the first COMMENT, not sentence, had the same suggestion. :)
- tolmasky 14y ago
  There are many good reasons not to add documentation as properties. For starters, it is a very US-centric approach to things. I would probably be annoyed if I was using a foreign language library that had random strings which contained text I did not understand in my objects. Secondly, the second you start putting documentation in your JSON, be prepared for services to break if you ever change that documentation. It may be silly to do "if (json._doc_.indexOf...)", but stranger things have happened and if you are making an API it is generally a bad tactic to require your clients not to be silly. "But I intend to have it in there solely because I can't use real comments -- I don't plan on shipping these". OK then probably no problem -- but at this point they're really no better than normal comments (with respect to the issue that Crockford brings up) since theres no reason you can't put compiler directives in the "comment" properties: { /* do something special mr. proprietary compiler */ "compiled_property": "magic" } vs. { "//" : "do something special mr. proprietary compiler" "compiled_property": "magic" } So the possibility of diverging incompatible implementations remains -- however I think the real reason this didn't happen wasn't the lack of comments but rather that JSON's biggest selling point is almost universal compatibility.
  - malandrew 14y ago
    It's not US-centric. It's English-centric and English is the lingua franca of software engineering as it is with many other professions. TBH, programming is and will always will be English centric and I would never feel 100% confident with any software engineer that isn't very proficient in English insofar as reading and writing are concerned. Practically every tome, text, blog or article of any real value in the field is published in English, and only once they are really well known are they translated to other languages. The only time the English speaking programming World is behind that of another language is when a new language is developed by a non-native English speaker (such as Lua developed in Brazil and Ruby developed in Japan). And even then no language would ever see popular adoption to the point of importance if it doesn't adopt English as the language of its source and its documentation. This isn't bigotry. This is just the way things are. FWIW, English isn't my first language, Portuguese is, but I have native fluency in English.
    - 14y ago
mcav 14y ago
(which any competent parser would handle just fine.)
dlubarov 14y ago
What if you need to encode arbitrary dictionaries, which may have keys like "//", rather than objects with specific named attributes? And what if you want multiple comments in the same scope (say, a comment before each attribute)? From the RFC: "The names within an object SHOULD be unique." In practice parsers will just override values, as JS does, but I think it would be legal to reject JSON with duplicate keys.
- polemic 14y ago
  IMHO, the complexity that this would introduce just highlights why it's a good idea not to have them. > "but I think it would be legal to reject JSON with duplicate keys." No it would not. `SHOULD` has a very specific meaning: 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. See http://www.ietf.org/rfc/rfc2119.txt http://www.ietf.org/rfc/rfc2119.txt An object with duplicate keys must be parsed, but the exactly result will be implementation specific (undefined).

{ "//": "I approve of the choice to omit comments from JSON." }

by DTrejo 14y ago

{ "//": "I approve of the choice to omit comments from JSON." }

generateui 14y ago

I was exactly thinking this when I was halfway reading the article. "Why not just add a property as comment?"

Yarnage 14y ago
Article? It's only 5 short sentences and the idea to add it as a property is the first comment on the post.
- generateui 14y ago
  Article, blogpost, same thing. The first sentence is > I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I do not read something on the lines of "you can also use a comment as a property". I wonder how you read that in the first sentence?
  - kcbanner 14y ago
    He said first comment, not first sentence.
  - Yarnage 14y ago
    >> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. >I do not read something on the lines of "you can also use a comment as a property". I wonder how you read that in the first sentence? lol, please re-read my comment. I said the first COMMENT, not sentence, had the same suggestion. :)
tolmasky 14y ago
There are many good reasons not to add documentation as properties. For starters, it is a very US-centric approach to things. I would probably be annoyed if I was using a foreign language library that had random strings which contained text I did not understand in my objects. Secondly, the second you start putting documentation in your JSON, be prepared for services to break if you ever change that documentation. It may be silly to do "if (json._doc_.indexOf...)", but stranger things have happened and if you are making an API it is generally a bad tactic to require your clients not to be silly. "But I intend to have it in there solely because I can't use real comments -- I don't plan on shipping these". OK then probably no problem -- but at this point they're really no better than normal comments (with respect to the issue that Crockford brings up) since theres no reason you can't put compiler directives in the "comment" properties: { /* do something special mr. proprietary compiler */ "compiled_property": "magic" } vs. { "//" : "do something special mr. proprietary compiler" "compiled_property": "magic" } So the possibility of diverging incompatible implementations remains -- however I think the real reason this didn't happen wasn't the lack of comments but rather that JSON's biggest selling point is almost universal compatibility.
- malandrew 14y ago
  It's not US-centric. It's English-centric and English is the lingua franca of software engineering as it is with many other professions. TBH, programming is and will always will be English centric and I would never feel 100% confident with any software engineer that isn't very proficient in English insofar as reading and writing are concerned. Practically every tome, text, blog or article of any real value in the field is published in English, and only once they are really well known are they translated to other languages. The only time the English speaking programming World is behind that of another language is when a new language is developed by a non-native English speaker (such as Lua developed in Brazil and Ruby developed in Japan). And even then no language would ever see popular adoption to the point of importance if it doesn't adopt English as the language of its source and its documentation. This isn't bigotry. This is just the way things are. FWIW, English isn't my first language, Portuguese is, but I have native fluency in English.
  - 14y ago

mcav 14y ago

(which any competent parser would handle just fine.)

dlubarov 14y ago

What if you need to encode arbitrary dictionaries, which may have keys like "//", rather than objects with specific named attributes? And what if you want multiple comments in the same scope (say, a comment before each attribute)? From the RFC: "The names within an object SHOULD be unique." In practice parsers will just override values, as JS does, but I think it would be legal to reject JSON with duplicate keys.

polemic 14y ago
IMHO, the complexity that this would introduce just highlights why it's a good idea not to have them. > "but I think it would be legal to reject JSON with duplicate keys." No it would not. `SHOULD` has a very specific meaning: 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. See http://www.ietf.org/rfc/rfc2119.txt http://www.ietf.org/rfc/rfc2119.txt An object with duplicate keys must be parsed, but the exactly result will be implementation specific (undefined).