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.
"colors": { "red":{"rgb":"fff"}", ... }
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.)
As you would with the original one as well.
> Then indexing by index is exactly what you want.
A much better use case. That said, the list order is kinda fragile, having an explicit row identifier might be worth adding. Especially since all of the columns are being explicitly called out instead of in their own list.
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.
Surely you wouldn't think of sending a piece of JSON over the wire with both name:color and rgb:color, regardless of whether that is what the recipient wants to operate on. You just have to let it unmarshall the data into whatever form it needs.
And before you argue that dictionaries can still be iterated in order, you better check the sibling threads where people are arguing you shouldn’t rely on that.
That said, my comment may a bit misdirected as a result, in which case: Mea Culpa.