My real-use case is too complex, but consider the simple scenario of a UI control that features an array of whatever controls, say checkboxes, and computes an aggregate property, i.e. a function of all the checkboxes states f(repeater.itemAt(0).checked, repeater.itemAt(1).checked, ...).
So I don't think this is violating the golden model-view separation rule. It is a UI-only repeater, the Repeater's model it's just an integer, and could be even constant. The aggregate property value (result of f()) is what is exchanged with the business-logic model. But depending on the complexity of f(), not always it is possible to do it without a for-loop iterating over the Repeater's delegates. Sometimes it is possible to invert the logic, and have each delegate do its small bit of computation, but that considerably increases the complexity, with respect to the top-down for-loop solution. Hence sometimes one would still prefer the for-loop approach. But if the count property (which I believe it's also there to work together with the .itemAt() method, and not just for showing a count to the user) was emitted in a more sensible moment, one would not need redundant null-checks at what .itemAt() returns. An additional consideration: is the for-loop approach relying on signal order? No, eventually there will be more property changes and the application will settle to the final (correct) state. It's just that the current order of signals causes more transitory states, some of which result in a JS error if we don't add those redundant null-checks. -- Federico Ferri
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest