Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Pretty JSON Revolution

ohler.com

Post reply on HN
Print view View original

91–100 of 159 posts

Re: The Pretty JSON Revolution

#91

Post by onetom »

graton wrote: post #32
peterohler wrote: post #23

Earlier quoted context omitted.

jq is a nice tool. oj is similar in many ways but different in others. jq has it's own proprietary query language while oj uses JSON path. The output options are also different with some overlap. Maybe jq will get a pretty output option after reading the article. :-)

> Maybe jq will get a pretty output option after reading the article. :-) In my experience jq already does pretty the output. Maybe I'm missing something in your comment.

"pretty output" meaning the one called "Human Style" in the article, where multiple array elements or key-value pairs are compacted onto 1 line, IF they fit into the specified line length.

Re: The Pretty JSON Revolution

#92

Post by peterohler »

ehnto wrote: post #78
peterohler wrote: post #34

Earlier quoted context omitted.

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

Thanks for the reply, the combined parameter was borne out of your real world usage so I'm glad it sounds like you'll keep it in. Hope I didn't come off cynical, this is a very cool feature for OjG.

All good. You were polite and friendly or at least I read it that way.

Re: The Pretty JSON Revolution

#94

Post by gmfawcett »

Latty wrote: post #80
gmfawcett wrote: post #77

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.

Agreed, and if you want to write tools that are conformant with both specs, you really don't have a choice. The RFC pretty much spells out this point: "JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences."

(This kind of text is why I prefer the ECMA document -- it's clearly written to be a normative standard, rather than as a field-report and Request for Comments.)

Re: The Pretty JSON Revolution

#97

Post by kccqzy »

peterohler wrote: post #62
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.

The colons really aren't necessary in most cases. Clojure does away with the colons for instance. And I'm pretty sure GP is referring to some kind of Lisp.

Re: The Pretty JSON Revolution

#98

Post by stevenpetryk »

breck wrote: post #84

Relevant plug: if Pretty Notations interest you, then you should keep an eye on Tree Notation https://treenotation.org/ .

This site uses only images to show the code but doesn't provide any text alternative for the image. Every image just has a `title` attribute of "Code you could hold in your hand"

Re: The Pretty JSON Revolution

#99

Post by Buttons840 »

msluyter wrote: post #85
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.

In theory, order shouldn't matter, right? But I recall seeing this trick for adding comments to json: { "foo": "this is a comment about foo", "foo": "actual value of foo that overwrites the comment" } The trick is that the second value value of foo overwrites the first. But, clearly, sorting would would wreak havoc here (if the value was used in the sort key). ;)

Yes. That is valid JSON.

A fun fact about MongoDB is it will actually store that JSON, both duplicate keys. The implication is that whatever MongoDB client you're using, that maps Mongo data to dictionaries/maps, is not capable of representing all valid MongoDB documents. It's important to recognize that Mongo may be storing data your client will not be able to access.

I learned this when the Python client was showing one value for a key, and the Ruby client was showing another value for the same key, and neither client was showing the whole document.

Re: The Pretty JSON Revolution

#100

Post by remram »

falcolas wrote: post #65
remram wrote: post #54

Earlier quoted context omitted.

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.

You should definitely optimize your data storage for the kind of operations you're going to do on them. However you're taking about the data transmission format here!

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.

Post reply on HN