I'm still trying to wrap my head around this proposal and I'm skeptical that it can be done at all.
I think there are two occasions where evaluation must be instant. The first is if your write property handler has any emits in it, and the second is if there are any other properties that depend on the changed value of your property. The first case is a little bit more difficult because if you have a guard around a signal emission Qt will always have to evaluate the property to determine whether or not the signal emission occurs. It would be good to structure things in a way beforehand that we can defer the invocation totally. And there is a third case in which the handler will modify class members that aren't properties. All in all I don't think this lazy evaluation could be done safely in a way that won't break existing code. We should rely on the developer to understand how properties work and structure their code around it, otherwise if we risk creating additional rules that will cause confusion and frustration to developers. We already have established rules on how the system works and you're going to add a whole another layer of magic in. I'd rather stick with the existing simple set of rolls and allow the developers to wield that rather than have us come up with logic that doesn't work 100% better. I think any guarded signal emission breaks the case for this magic binding evaluation. You're still going to have to call the handler every time in those cases, and any other deferred handlers will make it inconsistent. I think the logic being done here should be done by the developer and not Qt itself because Qt cannot account for everything that developer could potentially want and we would be restricting them unnecessarily. > Sent: Friday, July 24, 2020 at 1:45 PM > From: "Stottlemyer, Brett (B.S.)" <bstot...@ford.com> > To: "Volker Hilsheimer" <volker.hilshei...@qt.io> > Cc: "development@qt-project.org" <development@qt-project.org> > Subject: Re: [Development] QProperty and when evaluation occurs > > Hi Volker, > > On 7/23/20, 3:13 PM, "Volker Hilsheimer" <volker.hilshei...@qt.io> wrote: > > But why would we calculate the volume if nobody cares about the volume? :) > > Qt Remote Objects. I've got a headless service on one device, and a remote > UI for interacting with it. When signals are emitted (property change or > otherwise) by the service, the results are forwarded to the remote UI. > > Lazy evaluation probably works fine if the bindings are on the UI side, but > things break down if they are on the service side. That was why I was trying > to distinguish between derived properties _on a QObject_ vs bindings in a QML > UI. > > FWIW, pull-based systems are *much* more scalable than push-based systems, > because data is produced at the rate it can be consumed, not at the rate it > can be produced. That is unrelated to polling. > > That's only true if you know when you need to pull data. Otherwise it > _becomes_ polling. Also, I think you are assuming the pull is blocking, > which is not always valid. > > How will logging work? I often connect a lambda to a changed signal to > troubleshoot or log something. If such a routine were debug or > troubleshooting only, wouldn't that build behave fundamentally differently > (one doing immediate eval because of the signal connection, the other not)?. > > Thanks, > Brett > > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
