[Development] QProperty and library coding guide

[Ulf Hermann]

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