6 ms·

It's interesting, the first thing I thought of when looking at this was CSON (https://github.com/bevry/cson https://github.com/bevry/cson) which essentially ju

It's interesting, the first thing I thought of when looking at this was CSON (https://github.com/bevry/cson https://github.com/bevry/cson) which essentially just provides some syntactic sugar on top of JSON like CoffeeScript to JavaScript. I haven't look at this enough to really see the difference between JSON5 and CSON but at the surface it looks like its just CSON rebranded as JSON5. I agree with you that in general most json is machine generated and in most cases should never be manually created by people. It's a language for machines to talk to machines not machines to people. Granted it's sort of against JSONs philosophy but I also would love to see some more types added to JSON rather than syntactic sugar. There will always be libraries like CSON or CoffeeScript to add sugar, its better to make the base more useful and extendable.

jrpt 13y ago
Note that CSON is used in Atom.io, Github's new text editor: https://github.com/atom/language-ruby-on-rails/tree/master/grammars https://github.com/atom/language-ruby-on-rails/tree/master/g... I've used CSON before, main reason being that I wanted a config file with comments plus easy integration with a JS/CS project. YAML also works well.
callum85 13y ago
"most json is machine generated and in most cases should never be manually created by people" Except when sketching out a static JSON file that you'll eventually implement as a real API connected to a database, once you've experimented and arrived at a good structure. I do this a lot. I wouldn't output JSON5 from a live API, but I would use it for sample data in development.
- typicalbender 13y ago
  That's fair. My argument is that you shouldn't muddy the implementation of a protocol for debugging purposes. It creates unnecessary complications that then have to be dealt with on either end in software. I think the problem that you are bringing up is more of a development environment around creating good data structures in JSON rather than a pitfall in the protocol itself. I'm not saying JSON is perfect just providing a counter argument and stating a general belief I have about over complicating thing when a simple companion tool or something like CSON works just as well. CSON or CoffeeScript are good examples because they provide a more pleasurable environment for the developer but at the end up the day compile down to their native JSON or JavasScript respectively. I think we are in agreement in that I dont like the JSON5 syntax should necessarily be what's going over the wire.
mistercow 13y ago
It looks to me like a major difference between this and CSON is that this is safe and CSON is not. Literally the only difference between coffeescript.eval and cson.parseSync is that the latter runs in a sandbox. You can't screw up so badly as to cause global side effects, and you can't require modules, but that's where the safety ends. For example cson.parseSync("Math.sqrt")(4) will return 2, and cson.parseSync("1 while true") will cause an infinite loop. That's very powerful for config files; I'd much rather have my config say "y: Math.sqrt 2" than "y: 1.4142135623730951". But it means that you absolutely must not parse CSON that comes from an untrusted source. Now obviously JSON5 provides very little over JSON as a data-exchange format. In fact, the only practical advantage I see is that you can use Infinity as a value. I can see two use cases for this: 1. You have a web service for developers, and you want human-editable config files that can be parsed safely on the server side. CSON won't work there, and JSON5 would be nicer to work with than JSON. It's a good thing that JSON5 is a strict superset of JSON, because this is one hell of rare scenario. 2. You want your exchange format to be more human readable for debugging and testing. This use case isn't realistic, however, so long as JSON5.stringify is aliased to JSON.stringify.
- matthewrudy 13y ago
  The unsafe eval of objects in CSON seems to be an implementation quirk rathet than a feature. They're working on a static parser. Check out their WIP https://github.com/bevry/cson/issues/33 https://github.com/bevry/cson/issues/33
  - mistercow 13y ago
    That's good. It would be nice if they'd document the spec before doing this. Right now it's pretty unclear what is and isn't valid CSON, since any CoffeeScript code will run.

jrpt 13y ago

Note that CSON is used in Atom.io, Github's new text editor: https://github.com/atom/language-ruby-on-rails/tree/master/grammars https://github.com/atom/language-ruby-on-rails/tree/master/g... I've used CSON before, main reason being that I wanted a config file with comments plus easy integration with a JS/CS project. YAML also works well.

callum85 13y ago

"most json is machine generated and in most cases should never be manually created by people" Except when sketching out a static JSON file that you'll eventually implement as a real API connected to a database, once you've experimented and arrived at a good structure. I do this a lot. I wouldn't output JSON5 from a live API, but I would use it for sample data in development.

typicalbender 13y ago
That's fair. My argument is that you shouldn't muddy the implementation of a protocol for debugging purposes. It creates unnecessary complications that then have to be dealt with on either end in software. I think the problem that you are bringing up is more of a development environment around creating good data structures in JSON rather than a pitfall in the protocol itself. I'm not saying JSON is perfect just providing a counter argument and stating a general belief I have about over complicating thing when a simple companion tool or something like CSON works just as well. CSON or CoffeeScript are good examples because they provide a more pleasurable environment for the developer but at the end up the day compile down to their native JSON or JavasScript respectively. I think we are in agreement in that I dont like the JSON5 syntax should necessarily be what's going over the wire.

mistercow 13y ago

It looks to me like a major difference between this and CSON is that this is safe and CSON is not. Literally the only difference between coffeescript.eval and cson.parseSync is that the latter runs in a sandbox. You can't screw up so badly as to cause global side effects, and you can't require modules, but that's where the safety ends. For example cson.parseSync("Math.sqrt")(4) will return 2, and cson.parseSync("1 while true") will cause an infinite loop. That's very powerful for config files; I'd much rather have my config say "y: Math.sqrt 2" than "y: 1.4142135623730951". But it means that you absolutely must not parse CSON that comes from an untrusted source. Now obviously JSON5 provides very little over JSON as a data-exchange format. In fact, the only practical advantage I see is that you can use Infinity as a value. I can see two use cases for this: 1. You have a web service for developers, and you want human-editable config files that can be parsed safely on the server side. CSON won't work there, and JSON5 would be nicer to work with than JSON. It's a good thing that JSON5 is a strict superset of JSON, because this is one hell of rare scenario. 2. You want your exchange format to be more human readable for debugging and testing. This use case isn't realistic, however, so long as JSON5.stringify is aliased to JSON.stringify.

matthewrudy 13y ago
The unsafe eval of objects in CSON seems to be an implementation quirk rathet than a feature. They're working on a static parser. Check out their WIP https://github.com/bevry/cson/issues/33 https://github.com/bevry/cson/issues/33
- mistercow 13y ago
  That's good. It would be nice if they'd document the spec before doing this. Right now it's pretty unclear what is and isn't valid CSON, since any CoffeeScript code will run.