The Pretty JSON Revolution • Hacker News Board

Re: The Pretty JSON Revolution

#61

Post by SamBam » Tue, Feb 23, 2021, 4:05 PM UTC

ajuc wrote: post #38

selfmodruntime wrote: post #36

Earlier quoted context omitted.

Just because the data is structured this way in the example, doesn't mean it's not possible. What's hindering you from defining a class property for each color? "colors": { "red":{"rgb":"fff"}", ... }

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 json had a standardized way to remove redundancy for objects that always follow the same structure. One list of property names, and then everything in arrays.)

Re: The Pretty JSON Revolution

#62

Post by peterohler » Tue, Feb 23, 2021, 4:05 PM UTC

specialist wrote: post #45

Nicely done. First I've seen "SEN". Treating the colons as white space, as you've done with the commas, will move you one step closer to The Correct Answer™.

I suppose that is possible to remove the colons but it is nice having the extra reminder that the left side of the colon is a key and the right a value. That could easily become lost if a new line is inserted after the key.

SEN is new. After dealing with broken JSON due to commas missing or one at the end of an array and some of the team using Javascript this was a way of sucking in the broken JSON and fixing it.

Re: The Pretty JSON Revolution

#63

Post by peterohler » Tue, Feb 23, 2021, 4:06 PM UTC

dan-robertson wrote: post #52

peterohler wrote: post #18

Earlier quoted context omitted.

Can you explain what you mean by "like named"? The sorting helps a lot but I'm always interested in additional features.

I assume they mean vertical alignment like: [ { foo: a bar: 123.45 } { foo: abc bar: 6.7 } ]

Another post said something similar. An issue was added to add the feature. I think it is a good one to add.

Re: The Pretty JSON Revolution

#64

Post by asaph » Tue, Feb 23, 2021, 4:08 PM UTC

An incremental formatting tweak is not a revolution.

Re: The Pretty JSON Revolution

#65

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

remram wrote: post #54

falcolas wrote: post #39

Earlier quoted context omitted.

It's absolutely possible, yet the example doesn't do it. That's what the comment was calling out (plus a bit of superfluous "WTF").

What if you want to get the name for a hex color? Your "opinion" is just assumptions on how the data structure will be used, which you want to bake into the transmission format itself.

Then you're no worse off than if you had the original format. You'd have to iterate through the members in either case.

That said, given there are just shy of 17 million possible RBG combinations, and a small fraction those are of named colors, I'd personally continue to optimize for the named color case.

Re: The Pretty JSON Revolution

#66

Post by flaie » Tue, Feb 23, 2021, 4:09 PM UTC

AzzieElbab wrote: post #4

I expected a Mona Lisa as json by the end of this article

Here you go: https://pastiebin.com/603528abd6813

Re: The Pretty JSON Revolution

#67

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

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

Personally, aligning columns like that drives me nuts. It's awkward to maintain and makes things harder to actually read most of the time.

Re: The Pretty JSON Revolution

#68

Post by Garlef » Tue, Feb 23, 2021, 4:10 PM UTC

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

Re: The Pretty JSON Revolution

#69

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

igetspam wrote: post #12

taeric wrote: post #5

Earlier quoted context omitted.

I would be a little nervous sorting the keys. I thought it was not too uncommon for parsers to treat them as an alist where order matters. I guess so long as it is a stable sort, no big deal?

If you have a parser that's looking at keys in a hash as sorted, you should change your parser. Lists sure but not keys.

You're free to encode meaning in the order if you want, as the JSON spec explicitly punts on the issue:

"The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange."

https://www.ecma-international.org/wp-content/uploads/ECMA-4...

Re: The Pretty JSON Revolution

#70

Post by peterohler » Tue, Feb 23, 2021, 4:13 PM UTC

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 think you will find the JSON object members are not ordered while JSON array members are ordered. Since the JSON object members are not ordered, changing the order for display purposes does not change the data in any material way.