Apologies for reviving an old thread, but this just came up in a code review 
(https://codereview.qt-project.org/c/qt/qtremoteobjects/+/287828 if anyone is 
curious).

On 12/5/19, 11:56 AM, "Development on behalf of Olivier Goffart" 
<development-boun...@qt-project.org on behalf of oliv...@woboq.com> wrote:
    
    That's a source incompatible change, and the question is if we really want 
it.
    
...
    
    Do we want to automatically register the operators?
    Do we want to automatically register the types used in signal/slots, or 
just 
    the properties?
    
I've got a bit of a different take on this question.  For QtRO (and likely also 
for QML), I don't believe the problem of registration can be solved at compile 
time and we will always need a good/easy way to register at runtime.  I'm all 
for better compile time capability, but it will be problematic if that limits 
what can be registered at runtime.

The problem I've run in to is this: how are container types of runtime types 
are handled?  As Olivier mentioned, marshalling a custom type via QDataStream 
first puts the type's name in the stream, then the serialization of the 
instance.  That means common use-cases such as 'QVector<MyType>' and 'QMap<int, 
MyType>' are likely to be seen in the output.  What I'd like to see is 
container types for all basic types (i.e., statically registered by Qt) 
registered automatically (i.e., QVector<int>).  In addition, we need a good way 
to register relevant container types when types are added at runtime.  We are 
dynamically registering gadget and enum types without compile time help, but 
that is insufficient to allow containers of those types to be used.

The problem here is different, as the type will be fully defined and there 
won't be issues of forward declarations.  Does the template magic allow the 
containers to be registered as well?  Or is there a way to serialize container 
types as the type itself, as well as a potentially empty list of flags, where 
flags could include that the type is used in a container?  Otherwise handling 
`QHash<int, MyType>`, `QHash<QString, MyType>`, etc, become problematic...

Regards,
Brett

_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to