The Pretty JSON Revolution

Post by gmfawcett » Tue, Feb 23, 2021, 4:14 PM UTC

Garlef wrote: post #68

Garlef wrote: post #56

> 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

Post by falcolas » Tue, Feb 23, 2021, 4:15 PM UTC

SamBam wrote: post #61

ajuc wrote: post #38

Earlier quoted context omitted.

That's the point GP is making. Use JSON objects for dictionary-like structures instead of directly translating XML to JSON.

But the point is that it's always usage dependant. You key by color names, that seems obvious. But what if you want to look up a color by hex? Now you have to look through them all. What if this list is actually an order list of colors for different headings? And they can repeat? Then indexing by index is exactly what you want. Point is, you don't know the reason behind the data structure. (That said, I do wish the j…

Post by leoedin » Tue, Feb 23, 2021, 4:17 PM UTC

falcolas wrote: post #35

thechao wrote: post #24

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": […

Opinionated Opinion: That's an incredibly XML-ified version of a color table. I can clearly see the tags now. Can't just do a look up of a color color, instead I would have to iterate over the members or store it in a different data structure. Why even use JSON? Blech.

Post by ehnto » Tue, Feb 23, 2021, 4:19 PM UTC

peterohler wrote: post #34

ehnto wrote: post #26

> Those two parameters are specified as a float where the whole number part is the edge and the fractional part or the number of 10ths is the maximum depth on a single line. Is that a convention I'm not aware of? Seems a little obtuse and unnecessary, why not just accept two arguments? One less arbitrary usage detail to remember.

I keep the `-p` (pretty) option as a single option. Not a convention at all. I toyed with 80x3 and 80:3 but ended up with 80.3. You are right though, it probably make sense to support two options as well to avoid the unusual convention. Maybe a `-edge` and `-max-depth` options in addition. Issue created: https://github.com/ohler55/ojg/issues/36

Post by Latty » Tue, Feb 23, 2021, 4:24 PM UTC

gmfawcett wrote: post #77

Latty wrote: post #71

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. :)