[Development] QtCS19 Serialization session

[Thiago Macieira]

On Monday, 25 November 2019 13:59:28 PST Arnaud Clère wrote:
> Hi Thiago,
> 
> Regarding the last part:
> - it is frequent to have to save/load our types and then send/receive
> them to some server/device using,
> say QSettings/QJsonDocument for the first and JSON/CBOR for the latter

How many do so interchangeably. I'm not asking about whether we should support 
different serialisations. I am asking how many types would benefit from a 
single, standardised mechanism for multiple backends?

For example, a Rectangle in CBOR might be stored as (x1,y1,x2,y2) whereas the 
QSettings format might have been XxY+W+H, which means a generic solution will 
not work.

> - taking all Qt users into account, types like QList, QPoint are
> serialized to much more formats than we
> can imagine, so defining a zap method working the same way for
> QSettings, JSON, ... and also
> QAbstractItemModel, QQmlPropertyMap/List seems very useful to me.
> There are not much alternatives
> in how to serialize QList and the ones in CBOR are covered
> (definite/indefinite). QPoint::zap or, say,
> QColor::zap may not fit all use cases but the API allows to easily
> define another serialization.

I do not agree. Please back up that statement with data: how many types would 
benefit from a standardised serialisation? And why are you including item 
models in this, what do they have to do with serialisation?

> Now I guess the first part is more of a concern to you and I know the
> proposal do seem strange but hey,
> I used to understand assembly and now it looks strange to me!

Ok, that's actually a good point: assembly is very different from Qt-style 
C++, but it's not usually mixed with C++. What you're proposing is a very, 
very different API style that matches nothing in Qt and is meant to be used 
alongside Qt-style C++.

> One reason for the weirdness is abstraction but how do you gain a lot
> of flexibility without raising the
> abstraction level a little (think iterators...)? The abstractions
> themselves are familiar though:
> - record=struct=object=QMap=QAssociativeIterable=...
> - sequence=iterator=array=list=QSequentialIterable=...
> 
> Also, the fluent interface is just a little bit more elaborate version
> of QDataStream's fluent interface :
> 
> QDataStream Person::operator<<(...) {
>   return out
>     << person.name
>     << person.children; } // calling QList << then Person <<
> 
> QValueStatus Person::zap(...) {
>   return value.sequence()
>     .item(person.name)
>     .item(person.children); } // calling QList zap then Person zap

There is no example of fluent-like API in Qt. The closest we'll see of it in 
C++ is the ranges API with operator|, which are meant to imitate a shell 
pipeline anyway.

As I said, I don't like it and I fear a very different API could be confusing.

> Each method of the fluent interface will:
> 1. if the stream is valid and data matches the expected
> sequence/record/bool/... : consume the data and set referenced
> argument
> 2. else : do not move and report an error
> and so on with the next fluent interface call...

I understand what it's meant to do. I am saying I don't like that it does all 
it does.

It's also advising people to write inefficient code. For example, de-
serialising a record requires repeated iterations and is either O(n log n) for 
sorted records (like JSON) or O(n²) for unsorted ones like CBOR. In

  value.record()
    .item("a", a)
    .item("b", b)
    .item("c", c);

The .item() functions need to scan the QCborMap or QJsonObject container for 
the values being searched, which is O(n) and O(log n) respectively. A more 
efficient implementation would iterate over the keys, which is O(1).

> What do you guys think? Does it seem so un-Qtish as to bury or burn
> it? How can it be improved?

I don't know. I think there's value in having something, even if inefficient, 
since it allows for ensuring every type *can* be serialised, whether it has a 
better way of doing so or not. But there are other ways of accomplishing the 
same, like providing either a JSON serialisation or a CBOR one, which can be 
transported (however inefficiently) over other formats.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products