|
|
Scott Aron Bloom wrote on Friday, October 24, 2008 4:42 PM:
> ...
> For QT-Embedded, Nokia may want to consider documenting the current
> algorithm, stating for QT 4.X.X the order of connected functionality
> is this. And make that part of the binary compatibility requirements
> for release.
First, how would you make sure that changing the order of slot calls would
break "binary compatibility"? Because it would not! Changing the
/implementation/ only does /not/ change "binary compatibility" (your code would
still run with such a changed Qt library, because it would still be "binary
compatible" - it would simply behave wrongly and possibly crash, but not due to
"binary incompatibility").
But even if the docs would state that "the order of slot execution" is in the
"order of connection" I would feel uncomfortable if my design had to rely on
that *implicit* implementation detail.
I mean if you are sure that you are connecting only 4 signals - and only those
4 signals! - and the corresponding slots have to be called in that and that
order, and you connect them "statically" in one place (in some c'tor which is
only called once during application lifetime or so), you could probably live
with that.
But my experience shows that as soon as an application becomes a bit more
complex signal/slot handling can very quickly become very complicated to
understand! ("One signal triggering a slot, triggering another slot which
triggers another signal...", or the same slot called multiple times, because
with each little change the model emits a signal, ...)
Adding to that the fact that signal/slots can be *dynamically*
connected/disconnected at runtime, how would you make sure that no other code
has "connected that slot which was meant to be connected *after* your slot
which you are about to connect"? Etc.
Trying to debug something like that is likely to become a nightmare. Why?
Because you are using *implicitly* the fact that slots are called in the order
of connection. But if you connect from different places in code... uh oh...
So IMHO it is better to use an *explicit* design, with slot Priority or a
"Manager" class, which would not depend in which order you would connect (but
would only rely on the explicitly set "Priority", or the other mentioned
solution, with the programatically defined order of multiple emit():
private slots:
void handleModelChanged() {
// order explicitly defined
emit updateComponent1();
emit updateComponent2();
emit updateComponent3();
}
Cheers, Oliver
--
To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/
|
|