ceylon-sdk
ceylon-sdk copied to clipboard
eclipse-archived
ceylon.json::parse consider allowing non-quoted keys
The ceylon-js backend produces (nonstandard?) json that doesn't double-quote keys when possible, to save space. Perhaps ceylon.json should support this?
Maybe @chochos has an opinion on this.
The http://www.json.org standard does not seem to bless this. IMO quotes are required. But note that there's a difference between JSON and JS values. JSON is a subset of JS object literals. For example, in a JS object you can have values of any type, including dates, but not in JSON.
So I think the JS backend does not actually produce JSON, it produces JS code. And it's consistent with not being named foo-1-model.json but foo-1-model.js.
Now, sure we could add a relaxed mode, but that still won't allow you to parse JS values, so would that be enough/useful?
I'd like to see other examples of JSON with unquoted keys. If it's common in practice then we should support it.
To be clear, this isn't blocking me in any way, although I'd probably use it if it were available.
It is a feature of json-smart, used here: https://github.com/ceylon/ceylon-js/blob/master/src/main/java/com/redhat/ceylon/compiler/js/loader/ModelEncoder.java
There's also a feature grid I just noticed. A bit old, but has a few datapoints - https://code.google.com/p/json-smart/wiki/FeaturesTests
That's helpful @jvasileff, thank you. From the second document you link to it looks like it's more common to throw for the "Support non protected keys" case than to accept it (but only just). And by default they would all generate properly quoted keys. On that basis I'm tempted to say ceylon.json should stick to the RFC.
I'm also left wondering how much bigger our JS model would be if it had properly quoted keys.
Well, again, I don't think our model is JSON at all. In particular, it may contain JS expressions, I've no idea, but it would not surprise me. Which means JSON.parse would also fail to load it. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON for example. That method was added precisely so people could load JSON safely and stop using eval which would allow JS expressions which was a security risk. JSON does not.
So again, I think there are two orthogonal issues: one is about allowing invalid JSON in some cases, via an option. Fine, that can be discussed. But the bigger one is that our JS model is not JSON, and perhaps we want it to be?
I'm pretty sure that except for the keys our model is JSON-compliant. It would probably be good to make it so, but that of course means a backward incompatible change. (Assuming we'd change the file extension form .js to .json, if we only changed the format we'd be backward compatible)
@FroMage do you have any specific knowledge that the model is not JSON (aside from the quotes)? I'm interested because I'm reusing this code for Dart, although I haven't run into any problems so far, and I haven't noticed any sort of interpreter used for reading models during compilation.
@tombentley based on a completely unscientific test, sample size of one, the difference is 13%.
Oh, I didn't know it made it to RFC: https://tools.ietf.org/html/rfc7159
Its encoding section is interesting:
8.1. Character Encoding
JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encoding is UTF-8, and JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the maximum number of implementations; there are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32).
Implementations MUST NOT add a byte order mark to the beginning of a JSON text. In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.
do you have any specific knowledge that the model is not JSON
No, but since it was not made to be JSON (otherwise it'd use quotes) then I can only assume no care was taken to generate JSON-compliant values.
It's also wrapped inside a require.js function which makes it impossible to parse as JSON as-is without interpreting the file, or using require.js.
So an online JSON validator says it's valid aside from the key quoting, which I suppose is a good news.
