Matti spaketh: > > With this kind of dynamic programming environment it might be a fragile > > development practice to rely on the assumption that the framework will > > load elements in the same order all the way now and in the future. >
Aaron respondeth: > This is some sagely advice. > > When I say the order is undefined, that's what I mean ;) It is not that we > feel that this is a sensible order for some reason that we're keeping a > secret, it's just the order that the current implementation happens to run > them. This might change at any moment. > > What are you doing in your app that requires such strict ordering? Perhaps > we can suggest a more robust alternative. > I'm curious about the app-specific need for order-on-load also. (I don't doubt the possible need for it, I just want to understand it.) I've had similar try-and-see issues when connecting signals/slots in constructors which can lead to similar issues, since the (derived) class is not yet fully constructed when the base constructor is called. The question in that case would be "when" is that slot first fired, and is the sender/receiver class fully constructed? Of course, the answer is typically to move to two-stage construction (such as for calling an "init_()" after construction is completed), but a similar problem exists when forwarding "this" to base/member lists during system setup for coupled designs -- it generates a compiler warning, but it's legitimate when implementing designs with tight coupling (ideally we minimize that). I don't doubt guaranteed order may sometimes be important -- I'd assume some kind of "transactional" interface would be required to guarantee order. Such an interface could be interesting for other purposes, since in the declarative environment with bound properties, in theory there would be no other mechanism to guarantee order. So, I'd like to understand your order-on-load issues to see if they could relate to my order-on-bound-property-update issues. (IMHO these aren't fundamental "problems", but merely implications on how we *should* think when marrying the declarative and imperative.) --charley
_______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
