Re: Jason is getting MARRIED!

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2019-11-24 15:39:17

On Sun, Nov 24, 2019 at 12:26 AM Julien Blanc <julien.blanc_at_tgcm.eu> wrote:
> Not sure why you say this is an innovation. Maybe i missed something,
> but i dont see this much different than
> https://doc.qt.io/qt-5/qjsonvalue.html , which is around for years.

"Not much different" is still different, and those differences are
enough to disqualify QtJsonValue from being a vocabulary type:

* QtJsonValue does not support allocators
* QtJsonValue has an "undefined" state[1], reminiscent of valueless variants.
* QtJsonValue is part of a huge application framework. This alone is
enough to make it unsuitable as a vocabulary type: No one is writing
libraries that depend on Qt (imagine a Boost library being proposed
that required Qt).

> While it is ok for most use cases

Yes and these are the use cases which my library addresses.

> But the nice thing is that from what i see, it is entirely possible to
> do with current boost.json (didn't check about the serializer part,
> though).

I don't think so, the parser in boost.json is a SAX parser which is
somewhat inconvenient for parsing directly into user defined types. It
could be adapted into a generator using coroutines however.

> Using json types directly is fine for prototyping, for quickly written
> code that is not supposed to last for years. There is a market for
> this, this is useful. However, i would not rely on it for any code that
> is supposed to last or be reused amoung projects.

Counterexample:

<https://github.com/ripple/rippled/blob/232975bfdbde12a65499130d78f938f261c989ba/src/ripple/rpc/handlers/AccountInfo.cpp#L101>

There are others.

Thanks