Re: Jason is getting MARRIED!

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2019-12-08 15:48:51

On Sun, Dec 8, 2019 at 7:21 AM Bjorn Reese via Boost
<boost_at_[hidden]> wrote:
> The whole point of Boost.Serialization is to not go though an
> intermediate DOM, but to parse the data directly into the data
> structures provided by the user.

Then I am understanding you correctly.

You claim that Trial.Protocol is more suited than Boost.JSON for
integration with Boost.Serialization, because of the parser interface.
I don't think this is correct for the case of going directly to a
user-defined type, for the reason I stated earlier which you agree
with: that JSON does not prescribe the ordering of elements of
objects.

Consider a simple struct with members a, b, and c. We might archive it this way:

    a & BOOST_SERIALIZATION_NVP("a", a);
    b & BOOST_SERIALIZATION_NVP("b", b);
    c & BOOST_SERIALIZATION_NVP("c", c);

The resulting JSON might look like this:

    { "a" : 1, "b" : 2, "c" : 3 }

However, a perfectly valid encoding for an identical object could look
like this:

    { "c" : 3, "b" : 2, "a" : 1 }

In this case the serialization code above will not function correctly
given the alternate encoding of the JSON, because the code assumes
that the order of keys will be the same as when it was serialized. An
obvious solution is to parse into the intermediate DOM.

JSON is not an appropriate archive format for serialization, for the
reason that the order is not prescribed. You could implement a
Boost.Serialization archive for it, and the result would have the
*format* of JSON but it would not have the same semantics. Thus it
cannot really be considered JSON. And if we are going to choose a
format which is not-JSON, there are many better formats with less
overhead.

> Firstly, JSON Object is unordered, so any key permutation is a valid
> syntax. ECMA-404 is quite explicit about this.

Exactly.

>  If the data structure used by the user
> preserves the order, then so will the serialization.

Exactly. "if" the order of keys in the archive is preserved, then it
works. This is "not-JSON."

The use-case for a JSON serialization archive is not for the same
program to round-trip the data, otherwise there are more efficient
formats as I stated above. A useful use-case would be to serialize a
user-defined type T to JSON, in a way that other programs can access,
even if the keys are reordered. And to go the other way, from an
external program that produces a JSON, to deserializing into a
user-defined type T, even if the keys are reordered. A typical example
is a C++ server communicating with a JavaScript/HTML5 client. The
JavaScript program doesn't know about and doesn't care about
Boost.Serialization, nor does it preserve the order of keys.

> Your parser currently uses stack variables, so the adaptor has to use
> stackful coroutines which would incur two context-switches on every
> iteration.

I was referring to stackless coroutines. That type of coroutine still
has stack variables. It just doesn't save the entire stack at a
suspend point. The compiler can turn any function which has statically
bounded stack requirements into a "stackless coroutine."

Thanks