Am 08.08.2014 um 14:29 schrieb Bo Thorsen <b...@vikingsoft.eu>:
>> ...as soon as slots of multiple
>> classes are to be connected to a given signal "in a well-defined
>> order" such a design would probably be doomed to fail rather sooner
>> than later, IMHO.
>
> As long as your application is single threaded, then the order is
> perfectly well defined. If you think of connections as implementations
> of the visitor pattern with one visitor object in a list of signals,
> then it's not hard to do this. Emitting a signal and the connected slot
> calls are exactly the same as calling any C++ function, so the order is
> easy.
Well, I do agree there are certainly useful applications with a "well-defined
order" of slot calls.
E.g.
// some c'tor
Foo::Foo() {
connect(this, SIGNAL(whatever()), this, SLOT(mustBeCalledFirst()));
connect(this, SIGNAL(whatever()), this, SLOT(mustBeCalledSecond()));
connect(this, SIGNAL(whatever()), this, SLOT(mustBeCalledThird()));
...
}
is certainly easy to maintain (so far!), as all connects happen "locally"; and
even better if the slots are private (*), so no other class would be tempted to
connect the same signal (for whatever funny reason) to those slots - possibly
messing up the order.
But I really meant the case where you would pass along a given class instance
"across other class instances" (in order to "initialise" it or whatever), and
those other class instances would connect (and possibly even disconnect)
signals and slots, and you'd still expect this to happen "in an ordered
manner", then it takes only so long until Joe Programmer will "refactor" your
code, switch two lines of code where you instantiate those "other classes"
(which then connect the slots in a different order!) and bang! There you go,
absolute chaos! Even in a single-threaded application.
Okay, I agree again that I had a hard time contrieving an example where you'd
"realistically" would manage to "mess up the order in which you connect
signal/slots of a given instance".
But given my experience with signals (keyword: "endless signal/slot loop",
"signal which calls a slot which emits a signal which calls several slots
which... hey! Why does this method call take so long?!") it's hard enough to
deal with them properly. ;)
But I love the Qt signal/slot mechanism :)
(E.g. the Cocoa framework has like half a dozen different patterns to implement
the "model/observer" pattern: "Key-Value Observer", events, delegates...)
Cheers,
Oliver
(*) Yep, there is actually no such thing as "private slots": one can still
connect any signal to a "private slot" from "outside" the class and the slot
/will/ be called._______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
