config
config copied to clipboard
lightbend
Render format with formatted HOCON
Hi,
I find that in formatted HOCON, entry is rendered like key=value(if value is not an object) or key value(if value is an object). I think for better readability, why not use key = value? The string generated might be prettier in this format.
Besides, I think there are other small improvements that can be made. Such as: remove newline between short entries in a list to make it in a single line (like [0, 1, 2, 3]), and insert an extra newline after a long block.
Thanks!
When setFormatted=true (https://typesafehub.github.io/config/latest/api/com/typesafe/config/ConfigRenderOptions.html#setFormatted%28boolean%29 ) this sounds fine to me, except for cases that would require "look-ahead." That is, I think the code would probably get messier than is worthwhile if you have formatting rules that require looking at an entire list or entire object before outputting each field of said list or object. But otherwise, making things prettier is OK with me.
I agree with @acaly. I think there should be more render options to control the output.
Why is render() a method? How about adding a ConfigRenderer class which implements the operation and open this type for extension. That would also solve issuse #145
You would also have to make ConfigRenderOptions extensible to allow custom renderers to add their options.
The main thing to figure out there is what else would have to be public to implement render yourself. I think it uses some private API. We could see about adding what you need, though removing the method wouldn't be compatible, you don't have to use it.
It's a method primarily to use polymorphism (each ConfigValue knows how to render itself).
I was thinking that the method in ConfigImpl should simply use the new renderer class while the other types should implement an interface RenderableConfigValue which would give the renderer a clue or the renderer could offer methods to render different parts of config values and you could add a new render(renderer) method just like you currently have the methods which take StringBuilder and indentand the like.
That way, the code would be very similar to what it is right now but a lot of the hidden parts of the renderer (like whether JSON emits spaces around the colon) could be exposed for customization. Ideally, the new renderer should use fields for all strings with sensible defaults. Specific renderers could then overwrite them. So there is just a single keyValueSeparator field) which is = or _:_ (_ = space), depending on the formatting options.
+1 for adding more rendering options.
What I would need is ConfigRenderOptions.dotNotation(true) that would write all nested objects using dot notation whenever possible.
I propose a setting to disable reordering entries. Now I believe entries are in alphabetical order. The origin comments are already implemented, so keeping the original order should be easy to implement.
