Hacker News new | past | comments | ask | show | jobs | submit | peterohler's comments login

Oj supports a config file as well. .oj-config.sen. -help-config will describe it in more detail.


Works fine. Give it a try.


The title was meant to be fun. JSON format is a pretty light topic.


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.


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.


> After dealing with broken JSON...

Postel tried to warn us.

> ...nice having the extra reminder that the left side of the colon is a key and the right a value.

Totally. IMHO: whitespace, formatting, delimiters are for humans. The parsers can do without. With some exceptions, like your examples of quoting strings to remove ambiguity.


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.


Quite a variety of meanings. Some pretty funny.


Oj is actually pretty well known as a Ruby JSON parser. The OjG project is in the same family.


Pretty JSON is still just JSON. It should work with any JSON parser. Of course if it is being fed from one system to another there is no need to make the JSON anything other than compact one line JSON. Pretty is for human consumption.


Some parsers will reject JSON that has whitespace around the elements. Pretty JSON is really only for human consumption.


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.


An issue has been added to the repo. It is on the list now. Great idea, thanks. https://github.com/ohler55/ojg/issues/35


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: