-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HOCON reader? #1027
Comments
Oh I quite like the HOCON spec, defined at: https://github.com/lightbend/config/blob/master/HOCON.md It is JSON with extra features. Any JSON is valid HOCON (though not the other way). It is basically YAML done right (pretty old format too). This would be quite nice though entirely understandable if not done. |
I do not see this feature fit for this library. HOCON seems not the be used by many people, and at the same time, implementing a parser for it seems to be a lot of work... |
Related: #1024 |
I am using your JSON library for configuration files quite heavily (indeed, that is ALL I am using it for at the moment, and when I do start using it for data purposes it'll be via one of the binary formats you support), and the advantages of HOCON for handwritten files are substantial. If nothing else the addition of comments is a huge win, but I do think that comments shouldn't be added to JSON as a non-standard, breaking extension so doing it as a new JSON-derived format like HOCON is a better approach. |
I understand, but the HACON description seems rather complex, and I fear that adding this complexity to the library is not really an improvement. |
True enough -- they did "go to town" on the features. Unfortunately that means we're stuck between not wanting to support the full blown complexity of HOCON, and not wanting to break the regular JSON support (which deliberately left out comments). Looking through the HOCON spec, the only two features that I find compelling are comments and having consecutive strings (with no intervening punctuation) concatenated into one (mostly to enable multi-line strings without their strange triple-quoted approach). Seems unfortunate to advocate yet-another-format though. I don't want to be just tossing out names of format suggestions, but a quick search turned up one other that looks a whole lot less complex than HOCON: https://json5.org/ |
Eh, the most used features I enjoyed from my HOCON days was the ability to define defaults as variables and 'import' them, as well as including other files at positions (and comments as well). EDIT: This was for game data definitions so there was a lot of duplication otherwise without the including/importing. |
Unfortunately the include mechanism requires machinery and assumptions, although I suppose most of that could be delegated to a user lambda. |
The extension to HOCON is out of scope for this library. |
Feature Request
Since your JSON C++ API is mature and so much nicer than cpp-hocon's (not to mention WAY fewer dependencies), it would be really nice if this project were able to read HOCON files. I would imagine the include mechanism would be the trickiest part, whereas having the parser skip comments and cope with the format's extensions shouldn't be a big deal. Writing would be substantially more complex (due to the need to support adding includes, comments, etc) and is substantially less interesting since HOCON's primary goal seems to be to make config files more human writeable.
The text was updated successfully, but these errors were encountered: