From: VinÃcius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2020-09-19 12:44:51
Em sex., 18 de set. de 2020 Ã s 15:25, Glen Fernandes
> Hi VinÃcius,
> I know that one of your complaints was that Boost.JSON "does too
> little". But aside from these other JSON-related use cases that it
> does not cover, for what it does, it wasn't clear what the objection
> i.e. It sounded like your major objection to Boost.JSON was just that
> it did not ship with the lower level pull parser.
That's not how I work. I keep an eye to the discussions. For instance,
we have Peter Dimov who will be my stakeholder on the array of scalars
for improved CBOR case. I trust Peter Dimov here. I have no urge to
repeat somebody else's observation. Doing so would only contribute to
And when I say "it does too little", I mean what I say. Boost.JSON
design is solely concerned with 3 pieces:
- A read() function.
- A write() function.
- The variant class used in these 2 functions.
Anything else will receive no consideration to design at all. Can we
go in the opposite direction from parsers and review that? No, we
can't. Boost.JSON has no serialization framework. Compare these two
pretty-printer examples and you'll understand what I mean:
If I didn't happen to spend a few extra hours reviewing Boost.JSON
serialization framework, the reason is... Boost.JSON has nothing that
I can review/work-with here.
> I am interested in a JSON pull parser [...]
> Are you writing such a library with the intent of contributing it to Boost?
I do intend to write libraries for Boost, but not in the JSON domain.
The pull parser library that I use daily at work is the same one I
used to showcase pull parsers in the gawk plug-in. You can try to
persuade BjÃ¸rn -- he authored the library that I use -- if you want.
You can try to persuade Vinnie as well, but good luck there (I've been
trying for a long time).
> I understand that what Boost.JSON offers is a higher level
> abstraction. i.e. Boost.JSON could be implemented on top of such a
> JSON pull parser library. But that higher level abstraction is what
> many users want, correct?
> I said above I'd be in the market for a JSON pull parser. I prefer to
> have my own types, not reuse a DOM type provided by a library. I would
> think Boost should have both:
> * A library that offers boost::json::value for the people that want that
> * A library that has a pull parser for people like me
Boost is not a mere ceremony to award this and that library. Boost's
value relies on peer reviews, and that's my contribution here.
I know some proponents were very persistent on "DOM-tree is valuable",
but I won't be baited. If the container is all that matters, this
"library" should instead be a PR to Boost.Container.
And you aren't the only one who would prefer to use your own types.
The whole "my users never requested [...]" narrative fails to observe
that on the very first page from Boost.JSON documentation itself, "I
want to parse directly into my own data structures" is one of the few
FAQ items: https://master.json.cpp.al/json/overview.html#json.overview.frequently_asked_questions
Meanwhile the pull parser library that I use -- and it is older than
Boost.JSON -- has Boost.Serialization integration that only happens to
work thanks to the pull parser choice.
I'll answer Niall next, but I need a break right now, so it'll take a
few hours at least.
-- VinÃcius dos Santos Oliveira https://vinipsmaker.github.io/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk