[Development] QtCS19 Serialization session

[Arnaud Clère]

-----Original Message-----
From: Thiago Macieira <thiago.macieira at intel.com>
>
> My point is that I can see the value in providing a single method whereby our and users' types
> can provide a descriptive format for their serialisation, regardless what the serialisation backend is.
> That way, a single method could be used for XML, JSON, CBOR, DataStream, Future Whatchanameit.
>
> However, the API is very un-Qtish. I don't like reading a method and not knowing what it does.
> You can only know what the zap() methods do in context of the parameter passed.
>
> One more thing: how often do the same types need serialisation to multiple formats in a way
> that can be done generically?

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
- 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.

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!

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

Lastly, I think users will usually be more than API to use something
that just works and not have to dive
into specific APIs of QCbor* or QAbstractItemModel. But sure, as with
>>, they should be able to
understand what the API does, so let me try to explain it with has
little words as possible:
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...

Not so much magic after all... However, being able to do #2 is what
makes it much more interesting
than QDataStream >> to me.

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

Arnaud