Hi, I'm still trying to wrap my head around this concept, and starting a new thread to distinguish from the technical implementation discussion.
The two obvious cases: * Immediate evaluation. This is the current signal-based handling (ignoring queued for the moment). * Evaluate-on-Read (EoR). True lazy evaluation, where computations would never be made if no one asks. Kind of the opposite of CoW. EoR, though, seems not too useful in many cases; it seems to shift backwards towards polling. I expect Qt's HMI technologies (Widgets, QML, 3D) to have to shift(?) to the third case: * Render evaluation. When the render runs (nominally 30 or 60 frames per second), all "dirty" elements are evaluated, and the dirty flag is cleared. In this case, the evaluation is lazy, but the task of figuring out when to evaluate is handled by the renderer, not passed on to the user. How about: * EventLoop evaluation. Using area (or volume) as an example, a value depends on multiple variables that may all change, and calculating intermediate values before all updates are available is wasted cycles. In this case, the changes are programmatic such that at the end of the eventloop, the value can be computed. Ok, so what? I will assert that QObjects should use EventLoop evaluation if they have derived properties (like area()). An HMI or app that combines data from multiple objects will have to be responsible for how and when the evaluation of those elements is done. But a QObject, intended to be used by others, seems like it needs a better interface than a property that gets marked "dirty". Could something like `Qt::makeLoopPropertyBinding` (note the Loop) be implemented? Such that the property is evaluated at the end of the eventoop, and if changed/dirty, a signal is emitted at that point (possibly along the lines of QSingleShot(0))? This assumes part of the intent is to enable QObjects with derived properties at an interface level... Thoughts? Regards, Brett
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
