Em sex., 18 de set. de 2020 às 15:25, Glen Fernandes
Hi Vinícius,
Hi Glen,
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 was.
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 noise. 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: - https://master.json.cpp.al/json/examples.html#json.examples.pretty - https://github.com/breese/trial.protocol/blob/develop/example/json/pretty_pr... 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... 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/