If you are going to review the proposed approach I don't mind making a
voice call.
If someone says that this is alright, I will spend time and create a gerrit
patchset.
On Mon, Mar 23, 2020 at 11:45 AM Ulf Hermann wrote:
> Hi,
>
> We have the same problem in QML: We want to support user-defined
Hi.
It has been almost a year since I have raised the topic. A quick recap:
I was playing with serializaion and stumbled upon a problem with container
reflection.
In Qt there is an API to introspect container elements dynamically via the
meta type system.
But there is no way to populate a container
Prefixing identifiers is a slippery slope. In a fit of unifying coding
style everything will get prefixed. There will be slot_, m_, property_,
setter_/getter_ and so on.
Type name prefixing worth mentioning - unbelieably ugly convention
https://docs.microsoft.com/en-us/windows/win32/stg/coding-styl
Declaring variables
- Declare each variable on a separate line
https://wiki.qt.io/Qt_Coding_Style
Multiple declarations on the same line is not a valid argument as long as
they are forbidden.
Asterisk position, imho, should be based on the mental model.
X* x - is an identifier that names a
> Using QVariant as an intermediate data structure is not optimal to
read/write your QList
> It also prevents from directly using the QList type to guide
the deserialization. In QBind you do not need to register types at runtime
and you avoid losing data silently (instead you have static_asserts
> By the way, conversions through QVariant are *exactly* what I implemented
in
> the examples/corelib/serialization/convert tool.
Right, I've seen these to be helpful.
The global task would allow to code like this.
~
struct MyStruct
{
int property1;
QString property2;
};
class MyObject
{
> You can be sure that the conversion from QList to
QSequentialIterable
> will be successful, but the other way around is not given.
QSequentialIterable
> can contain QVariants of different types. I'm curious what is the use
case for
> the feature?
Imagine one could call a Q_INVOKABLE or a slot gi
Thanks for the answers.
> 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.
Just wanted to clarify, that I am working on a solution, which i
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.
The general idea is to create a playground project for automatic
(de)serialization for Qt (not manual, i.e
