Re: [review] [json] My JSON review

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-09-21 15:48:11

On Mon, Sep 21, 2020 at 8:26 AM Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> To make people happy I think it's easier to provide a separate
> incremental push parser and a non-incremental pull parser.
> I don't think those should be in separate libraries, consistency is key.

I disagree. I don't have any special expertise to bring to the table
when it comes to pull parsers. I don't need them for the applications
and libraries that I am developing. However I am proficient at writing
the kind of code needed for push parsing, and implementing containers
(having already done so many times in the past). If I were to
implement a JSON serialization library (which is what you are asking
for) I would be doing so basically from a fresh start. What I am
saying is that this type of implementation does not play to my
strength. There have already been individuals who proclaim to be
subject matter experts in this area - they should write this library.

"Consistency" is a vague goal. But here's what's not vague. Having
JSON serialization in its own library means it gets its own Travis
limits for individual forks. CI turnaround is faster. Tests run
faster. The documentation is focused only on the serialization
aspects. Users who need only JSON serialization, can use the
particular library without also bringing in a JSON DOM library. And
vice versa. To me, this separation of concerns has more value than
"consistency."

I also have to wonder, to what consistency do you refer? The parser
will not be consistent. One is pull, the other is push. The DOM will
not be consistent. One has it, the other doesn't. Serialization is in
a similar situation. In fact, when you compare a JSON DOM library to a
JSON Serialization library, they are about as different as you can
imagine, sharing only the nominal serialization format. Not much code
would be shared between a DOM and a serialization library.

I see nothing wrong with Boost.JSON being the library that users go to
when they want a container that is suitable as an interchange type.
And I see nothing wrong with someone proposing a new library that
implements JSON serialization to and from user-defined types, with
pull parsers, no DOM, and maybe even quotes from Aleister Crowley in
the documentation. Having fine-grained libraries which target narrow
user needs is something we should all agree is good for Boost (and C++
in general).

Regards