On Sep 22, 2020, at 4:12 AM, Gavin Lambert via Boost
wrote: It seems less suited for JSON as configuration file -- while it can parse such files (via common extensions such as ignoring comments and trailing commas) it lacks means to pretty-print and to round-trip the comments, which would be essential if writing back a config file intended for human use. However while supporting this use case would be nice, I don't consider it mandatory.
Out of curiosity, why would you want to round-trip the comments from a config file? Wouldn’t you want to write the comments anew each time you write the file, in case your code version had newer or corrected info? (I’m assuming the comments are like “// the following setting enables self-destruct (default=false)”) I would think you’d want such “comments” to come from a schema, not the DOM. (Of course that would require schema-based serialization, or some form of serialization control, but that’s a separate topic) Or do you want the human to be able to change comments and/or write their own, that get saved back? We have something like that at my job, but it’s a first-class/normal citizen in the DOM, using normal json-object string field entries named “description”. That way users can set descriptions for config objects regardless whether they edit config files by hand, or use a GUI, or whatever. -hadriel