Re: [review] [json] My JSON review

From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2020-09-21 19:18:59

> On 21. Sep 2020, at 19:57, Hans Dembinski <hans.dembinski_at_[hidden]> wrote:
> 
>> 
>> On 21. Sep 2020, at 19:44, Vinnie Falco via Boost <boost_at_[hidden]> wrote:
>> 
>> On Mon, Sep 21, 2020 at 10:29 AM Mathias Gaunard
>> <mathias.gaunard_at_[hidden]> wrote:
>>>>> In both cases, I'd like to read/write my data from/to JSON with the
>>>>> same framework.
>>>> 
>>>> Why? What specifically, is the requirement here?
>>> 
>>> What I'd like is a way to describe how my C++ types map to a key-value
>>> structure with normalized types so that I can easily convert my
>>> objects back and forth through a structured self-describing and
>>> human-readable interchange format.
>> 
>> Right, but what I'm asking you is: *specifically* in what way would a
>> framework that offers both JSON DOM and JSON Serialization be
>> "consistent?" Can you show in terms of declarations, what that would
>> look like? In other words I'm asking you to show using example code
>> how putting these two separate concerns in a single library would
>> offer benefits over having them in separate libraries.
> 
> The Boost.Serialization framework is able to do both. The two things needs are 
> a) a JSON archive that follows the Archive concept 
> b) a serialize function for json::value
> 
> Once you have these two, you can convert the DOM type and/or any custom type to JSON and back.

On second thought, the Archive concept probably needs an extension to work with json::value. While writing is no problem, reading is a challenge.

For reading, Boost.Serialization usually relies on the fact that the type that is going to be read next from the archive is statically known. In case of a boost::variant, a polymorphic type similar to json::value, it reads a type id first (some integer) and then calls the appropriate code based on that value.

While that would also work for the json::value type, we obviously don't want to store explicit type ids in JSON. So the type info would have to come from the Archive itself in this case, which probably could do some look-ahead into the stream to provide info like "then next type in the stream is a number/string/array of 3 elements".

Bottom line, it is not so easy as I thought.