5 ms·

I think now is a good time to re-quote the man himself... Douglas Crockford.. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.googl

by RoryH 10y ago

I think now is a good time to re-quote the man himself... Douglas Crockford.. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG... I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

realharo 10y ago
The second part basically says "don't use JSON for config files, use some unspecified JSON superset".
- efaref 10y ago
  I find that YAML (a JSON superset) for config and JSON/CBOR on the wire works quite well.
- lmm 10y ago
  https://github.com/typesafehub/config/blob/master/HOCON.md https://github.com/typesafehub/config/blob/master/HOCON.md makes it specified.
coldtea 10y 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 call BS. If people want to have custom parsing directives they can send them out of band, encode them in the filename, or whatever. But they don't. And I've not seen this happening with most other serialisation formats either, so why would JSON be a particular target? After all it's value comes from being trivially parsable across languages, and that would be killed by custom parsing directives. Those wanting those would also implement their own parsers etc. Addition: Besides, reading comments to decide how to parse, implies either "comments on top of the file" or a "2 stage parsing". With 2 stage parsing, you could implement comments and whetever else yourself, even in pure JSON anyway. As for "comments on top of the file", well, just disallow them (only allow comments after the first JSON object starts), and no issue with "parsing directives" anymore...
- beagle3 10y ago
  When I read this statement, I was thinking of Pascal style comment directives, e.g. { field1: 'hello', //#if (protocol_version>3) field2: 'hello', //#endif /* #charset utf-8 */ field3: 'world world' /* #charset default */ } Which falls into neither "comments on top" nor "2 stage parsing". Unlike the C preprocessor, which "eats" whole lines starting with #, Pascal used a {$directive arguments} inline comment style.
- mort96 10y ago
  If people really wanted parsing directives, they could just say that keys starting with # and their values are parsing directives - e.g: { "#if": "parserversion > 1.5", "key": "somevalue", "#else": "", "key": "othervalue" } Thought I also don't really see any reason to include parsing directivesin JSON.
  - tfm 10y ago
    Alas, there's no guarantee that the order of key/value pairs within an object will be preserved (not even within JS anymore!). But that's okay, we can always reformat the ordered data as an array or write a custom parser ... oh. I don't see any reason to include parsing directives in JSON either, but it's a wild world out there and people do all sorts of strange things. Seems that a few of those folks were working at Yahoo and made the mistake of letting Doug see their code when JSON was in prototype phase, so no JSON comments for anyone. Whoops!
  - DonHopkins 10y ago
    If you're going to design something like that, it's wise to make sure it can be represented as valid JSON. Since JSON objects don't support order or repeated keys, that syntax can't be represented, edited or processed by the rich ecosystem of JSON tools. Most decent JSON editors will show that text with squigly red underlines. It's not worth giving up interoperability, and having to make yet another new set of tools for an incompatible syntax. That was the mistake that the Angular 2 template syntax made. But XML-based templating languages like Genshi [1] show how you can obey the rules of XML, use namespaces correctly, support element, attribute and text based expressions, looping, logic and macros, and it works just fine and interoperates perfectly with existing tools. Genshi was based on another Python based XML templating system called Kid [2], which itself was influenced by Zope's page templates, TAL template attribute language, TALES expressions [3] and METAL templates [4]. Genshi and Kid templates are simple and easy to use compared to the conglomeration of Zope stuff. Here is the essential trick, described in the Zope manual, which all those languages share, that makes it possible to sidestep the fact that attributes are not ordered: When there is only one TAL statement per element, the order in which they are executed is simple. Starting with the root element, each element’s statements are executed, then each of its child elements is visited, in order, to do the same. Any combination of statements may appear on the same elements, except that the content and replace statements may not appear together. Due to the fact that TAL sees statements as XML attributes, even in HTML documents, it cannot use the order in which statements are written in the tag to determine the order in which they are executed. TAL must also forbid multiples of the same kind of statement on a single element, so it is sufficient to arrange the kinds of statement in a precedence list. When an element has multiple statements, they are executed in this order: 1) define 2) condition 3) repeat 4) content or replace 5) attributes 6) omit-tag It would be great to have a Genshi-like templating language for JSON, tightly integrated with JavaScript the same way Genshi is integrated with Python. [1] https://genshi.edgewall.org/ https://genshi.edgewall.org/ [2] http://turbogears.org/1.0/docs/GettingStarted/Kid.html http://turbogears.org/1.0/docs/GettingStarted/Kid.html [3] https://docs.zope.org/zope2/zope2book/AppendixC.html https://docs.zope.org/zope2/zope2book/AppendixC.html [4] https://docs.zope.org/zope2/zope2book/AppendixC.html#metal-overview https://docs.zope.org/zope2/zope2book/AppendixC.html#metal-o...
moonshinefe 10y ago
Okay, so the reasoning is we remove a highly useful feature that most people who use JSON regularly want, because some people were abusing it and using terrible practices? That's terrible reasoning.
- lmm 10y ago
  http://www.haskellforall.com/2016/04/worst-practices-should-be-hard.html http://www.haskellforall.com/2016/04/worst-practices-should-... . And it seems to have worked out well for JSON.
DonHopkins 10y ago
Ugh. Comments are also useful for disabling things without actually deleting them. My hackey in-band work-around is for the persistence layer (and other code) to ignore any dictionaries in an array that have the "//" key, so I can put a "//": "DISABLED" key at the top of a dict to disable it (and document that and why it's disabled).

by RoryH 10y ago

realharo 10y ago

The second part basically says "don't use JSON for config files, use some unspecified JSON superset".

efaref 10y ago
I find that YAML (a JSON superset) for config and JSON/CBOR on the wire works quite well.
lmm 10y ago
https://github.com/typesafehub/config/blob/master/HOCON.md https://github.com/typesafehub/config/blob/master/HOCON.md makes it specified.

coldtea 10y 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 call BS. If people want to have custom parsing directives they can send them out of band, encode them in the filename, or whatever. But they don't. And I've not seen this happening with most other serialisation formats either, so why would JSON be a particular target? After all it's value comes from being trivially parsable across languages, and that would be killed by custom parsing directives. Those wanting those would also implement their own parsers etc. Addition: Besides, reading comments to decide how to parse, implies either "comments on top of the file" or a "2 stage parsing". With 2 stage parsing, you could implement comments and whetever else yourself, even in pure JSON anyway. As for "comments on top of the file", well, just disallow them (only allow comments after the first JSON object starts), and no issue with "parsing directives" anymore...

beagle3 10y ago
When I read this statement, I was thinking of Pascal style comment directives, e.g. { field1: 'hello', //#if (protocol_version>3) field2: 'hello', //#endif /* #charset utf-8 */ field3: 'world world' /* #charset default */ } Which falls into neither "comments on top" nor "2 stage parsing". Unlike the C preprocessor, which "eats" whole lines starting with #, Pascal used a {$directive arguments} inline comment style.
mort96 10y ago
If people really wanted parsing directives, they could just say that keys starting with # and their values are parsing directives - e.g: { "#if": "parserversion > 1.5", "key": "somevalue", "#else": "", "key": "othervalue" } Thought I also don't really see any reason to include parsing directivesin JSON.
- tfm 10y ago
  Alas, there's no guarantee that the order of key/value pairs within an object will be preserved (not even within JS anymore!). But that's okay, we can always reformat the ordered data as an array or write a custom parser ... oh. I don't see any reason to include parsing directives in JSON either, but it's a wild world out there and people do all sorts of strange things. Seems that a few of those folks were working at Yahoo and made the mistake of letting Doug see their code when JSON was in prototype phase, so no JSON comments for anyone. Whoops!
- DonHopkins 10y ago
  If you're going to design something like that, it's wise to make sure it can be represented as valid JSON. Since JSON objects don't support order or repeated keys, that syntax can't be represented, edited or processed by the rich ecosystem of JSON tools. Most decent JSON editors will show that text with squigly red underlines. It's not worth giving up interoperability, and having to make yet another new set of tools for an incompatible syntax. That was the mistake that the Angular 2 template syntax made. But XML-based templating languages like Genshi [1] show how you can obey the rules of XML, use namespaces correctly, support element, attribute and text based expressions, looping, logic and macros, and it works just fine and interoperates perfectly with existing tools. Genshi was based on another Python based XML templating system called Kid [2], which itself was influenced by Zope's page templates, TAL template attribute language, TALES expressions [3] and METAL templates [4]. Genshi and Kid templates are simple and easy to use compared to the conglomeration of Zope stuff. Here is the essential trick, described in the Zope manual, which all those languages share, that makes it possible to sidestep the fact that attributes are not ordered: When there is only one TAL statement per element, the order in which they are executed is simple. Starting with the root element, each element’s statements are executed, then each of its child elements is visited, in order, to do the same. Any combination of statements may appear on the same elements, except that the content and replace statements may not appear together. Due to the fact that TAL sees statements as XML attributes, even in HTML documents, it cannot use the order in which statements are written in the tag to determine the order in which they are executed. TAL must also forbid multiples of the same kind of statement on a single element, so it is sufficient to arrange the kinds of statement in a precedence list. When an element has multiple statements, they are executed in this order: 1) define 2) condition 3) repeat 4) content or replace 5) attributes 6) omit-tag It would be great to have a Genshi-like templating language for JSON, tightly integrated with JavaScript the same way Genshi is integrated with Python. [1] https://genshi.edgewall.org/ https://genshi.edgewall.org/ [2] http://turbogears.org/1.0/docs/GettingStarted/Kid.html http://turbogears.org/1.0/docs/GettingStarted/Kid.html [3] https://docs.zope.org/zope2/zope2book/AppendixC.html https://docs.zope.org/zope2/zope2book/AppendixC.html [4] https://docs.zope.org/zope2/zope2book/AppendixC.html#metal-overview https://docs.zope.org/zope2/zope2book/AppendixC.html#metal-o...

moonshinefe 10y ago

Okay, so the reasoning is we remove a highly useful feature that most people who use JSON regularly want, because some people were abusing it and using terrible practices? That's terrible reasoning.

lmm 10y ago
http://www.haskellforall.com/2016/04/worst-practices-should-be-hard.html http://www.haskellforall.com/2016/04/worst-practices-should-... . And it seems to have worked out well for JSON.

DonHopkins 10y ago

Ugh. Comments are also useful for disabling things without actually deleting them. My hackey in-band work-around is for the persistence layer (and other code) to ignore any dictionaries in an array that have the "//" key, so I can put a "//": "DISABLED" key at the top of a dict to disable it (and document that and why it's disabled).