From: Gavin Lambert (boost_at_[hidden])
Date: 2020-09-23 02:15:29
On 23/09/2020 13:56, Hadriel Kaplan wrote:
> 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)
No, I wasn't thinking of comments as software-provided documentation.
But that could still work if the serialiser set the comment before
writing the file. Though I guess it'd have to be more careful if there
were human-specified comments as well.
> 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.
Yes, I was envisaging the human to be the one creating the comments,
either as notes for themselves, or more commonly commenting out a
particular setting because they don't want it to take effect but don't
want to actually delete it.
You can work around these things in strict JSON by altering the key name
(or using a reserved key name, as you suggested), and that's fine,
provided that it round-trips unknown keys. But it's more awkward than
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk