On Monday, 1 April 2019 11:09:27 CEST Vasily Pupkin wrote: > Hi. > > I would like to submit a patch. Since it is probably going to break binary > compatibility and is mostly about coding conventions, I would like to have > some feedback before investing time.
If it's going to break BC, it's a Qt6 API only. Please design your change so that it exists inside an #ifdef alongside the existing code. > The general idea is to create a playground project for automatic > (de)serialization for Qt (not manual, i.e. overriding operators). The only > stopper is container deserialization. I'm not sure I want to see more Datastream-based serialisation. The code there is too fragile and not compatible enough with standards. I recommend you reconsider and think about a more standard format. > Seriazation is quite straightforward via QSequentialIterable and > QAssociativeIterable. But deserialization is currently possible only by > QMetaType::registerConverter. I think, that this is would be so nice to > have an ability to create a container via QVariant from collection of > QVariant instances without a need for custom converters. > ~ > QList<QVariant> variantContainer; > variantContainer.append(QVariant(123)); > variantContainer.append(QVariant(321)); > QVariant variant(QVariant::fromValue(variantContainer)); > QVariant containerVariant(variant.convert(qMetaTypeId<QList<int> >())); > ~ This is a very lossy conversion without sufficient error reporting. That's an example of why I don't think we should invest more time in this type of API. > And so I have stumbled into a problem. QSequentialIterable and > QAssociativeIterable related code is scattered across <qvariant.h> and > <qmetatype.h>. All related conversions are conveyed in templates, instead > of > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.cpp#n > 387 . > I just don't feel, that further > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h#n78 > 2 and > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qmetatype.h#n1 > 121 development > is the way to go. Nor I. That code is black magic to me and I don't touch it. > And so the question is: should I try to refactor sequential and associative > iterators, so templates are used only to staticaly gather information about > containers and conversions are made in qvariant.cpp, where they belong? I suggest you leave it alone. > It also would be nice to hear, if someone acknowledges this conversion > feature to be of use. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
