Re: [review][json] My review

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 
comments.