However, for Q_GADGET this would fall apart.
Actually, with a Q_GADGET you usually don't have a private object.
That's the whole point of it. Then you don't need property wrappers, either.
So, to confine the property wrapper to the QObject it belongs to we can
delete the copy and move constructors and assignment operators. (we
still need a trick to prevent construction outside the object, though)
I am confused. Removing the struct means we’re back to a
setFoo()/foo() style API, and especially, we have a different API for
people using Property directly and what we provide in our public API.
That simply doesn’t make sense.
I was assuming we'd also add setBindingOnFoo() etc. Yes, that would be
different API than what we provide for QProperty directly. If we can
avoid it, we should.
I really want API consistency. We have QProperty as a public class
for our users. Even if we need to hide our data for BC reasons, our
API should not feel different than that one.
Agreed, but the safety concerns Giuseppe has brought up are valid. We
need to make sure the property wrappers don't escape the object they
belong to. That might be possible after all, though.
regards,
Ulf
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
