[Development] QProperty and library coding guide

[Ulf Hermann]

> I must be missing something.  I tend to think of eventloops with notify 
> signals are an improvement over polling.  You statement seems to say 
> that asking for a value is better, and notifications are to be avoided?

I'm not saying that you should go back to polling. In the case that you 
have genuine events, for example input or network activity, signals may 
just be the thing you need. This whole discussion is specifically about 
properties and their _change_ signals.

Mind that the propagation of dirty flags across a binding graph is a 
kind of "change signal" in its own right. With QProperty, we just don't 
calculate the values right away when we notice that a related property 
has changed. Why is that?

Properties can change fairly often, and synchronously triggering a chain 
of calculations whenever some property changes can be inefficient and 
can lead to unexpected intermediate values. This is why we introduce 
lazy evaluation for property bindings.

With this system, on some level, you indeed have to poll a property to 
make something happen outside the system. However, certain technologies 
are inherently based on polling. For example the scene graph rendering a 
frame every 16ms will poll for changed items every time. For this, a 
lazy evaluation strategy makes more sense than the usual change signals.

If you want to take advantage of lazy evaluation in such places, you 
should stop using the change signals there, though. Whenever a property 
has a change signal, it and everything it depends on needs to be 
evaluated eagerly.

best,
Ulf