101–110 of 159 posts
I recall seeing something that claimed all JSON is syntactically valid JavaScript. If that's correct, shouldn't it be possible to use JS code formatting engines to intelligently format JSON?
JSON.stringify(JSON.parse(require('fs').readfileSync('myfile.json')),null,2);
> JSON can be made prettier by sorting the JSON object members by element keys. This seems to be a bad idea. The JSON language spec has ORDERED object members. But the order is arbitrary (precisely the one given in the JSON string) and does not have to be the lexicographic. Sorting the object members by default would introduce problems whenever the order matters to the consumer of the JSON.
False. “An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array.” [emphasis added][0]
Earlier quoted context omitted.
The spec[1] says: > An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. "whenever the order matters to the consumer of the JSON" should be never. More pragmatically, regardless of what the spec says, a ton of JSON tooling assumes the order doesn't matter and relying on it would be a big mistake. [1]: https://…
> More pragmatically, regardless of what the spec says, a ton of JSON tooling assumes the order doesn't matter and relying on it would be a big mistake. Agreed. But this does not mean that a tool should break it. My assumption would be that fn(parse(pretty_print(someJSONString))) should always evaluate to the same as fn(someJSONString) (for all functions fn)
Earlier quoted context omitted.
The spec[1] says: > An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. "whenever the order matters to the consumer of the JSON" should be never. More pragmatically, regardless of what the spec says, a ton of JSON tooling assumes the order doesn't matter and relying on it would be a big mistake. [1]: https://…
The other spec (ECMA-404) disagrees with RFC 7159 on this point. That's the great thing about specs -- if you don't like what one says, there's always another to support your position. :)
Earlier quoted context omitted.
The other spec (ECMA-404) disagrees with RFC 7159 on this point. That's the great thing about specs -- if you don't like what one says, there's always another to support your position. :)
Well, falling back to the pragmatist position: a lot of JSON tooling assumes the order isn't relevant semantically. Not taking that position will cause you a lot of headaches.
JSON is a serialization format. Its components inherently have a serial order. You can't change this any more than you can legislate the value of pi to be 3.
I have trouble getting excited about tools to prettify JSON as long as the guy controlling the standard has a stubborn attitude about allowing comments or decent storage for long/multiline strings. At this point I honestly take XML over JSON where I have a choice because of CDATA and comments.
Earlier quoted context omitted.
> More pragmatically, regardless of what the spec says, a ton of JSON tooling assumes the order doesn't matter and relying on it would be a big mistake. Agreed. But this does not mean that a tool should break it. My assumption would be that fn(parse(pretty_print(someJSONString))) should always evaluate to the same as fn(someJSONString) (for all functions fn)
JavaScript objects are ordered maps (as are PHP’s arrays, iirc): it’s not common, but relying on this is specified behavior in JavaScript: it would be a little surprising for JSON object literals to follow a different rule.
JSON object literals expressly follow a different rule (are expliclty unordered) per the IETF specs and have no specific significance to order at the JSON level though some might conceivably be introduced in ancillary specifications or tooling per the bigECMA spec.
JSON is syntactically a subset of JS but not semantically identical. Unambiguous order would require an array of one-entry objects in JSON.
Please: { "colors": [ { "color": "black", "hex": "#000", "rgb": [ 0, 0, 0 ] }, { "color": "red", "hex": "#f00", "rgb": [ 255, 0, 0 ] }, { "color": "yellow", "hex": "#ff0", "rgb": [ 255, 255, 0 ] }, { "color": "green", "hex": "#0f0", "rgb": [ 0, 255, 0 ] }, { "color": "cyan", "hex": "#0ff", "rgb": [ 0, 255, 255 ] }, { "color": "blue", "hex": "#00f", "rgb": [ 0, 0, 255 ] }, { "color": "magenta", "hex": "#f0f", "rgb": […
Ouch! This is borderline unreadable to me. Even more so when there's a value of length, say, 50 for the one of color keys.
More importantly, what’s more readable to you?
Earlier quoted context omitted.
Also in violation of the spec: > An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. https://tools.ietf.org/html/rfc7159#section-1
The spec does call out that some parsers deal with this. And since it is javascript based, leniency is the norm. That is, you could rely on this and but be aware of it, is my point. Firefox, for example, will happily take an object with duplicates and report only the last one.
That said, I agree that being aware of this is important if you're emitting JSON. You'd think nobody would ever address a JSON object by its ordinal position, but programmers are lazy and worse, think they're clever. :)
> JSON can be made prettier by sorting the JSON object members by element keys. This seems to be a bad idea. The JSON language spec has ORDERED object members. But the order is arbitrary (precisely the one given in the JSON string) and does not have to be the lexicographic. Sorting the object members by default would introduce problems whenever the order matters to the consumer of the JSON.
I checked the spec again: It's unclear: At one point it says "An object is an unordered set of name/value pairs." while in the actual grammar it is ordered: object '{' ws '}' '{' members '}' members member member ',' members