[Interest] Signal and Slot mechansim in Qt4.8.x

[Till Oliver Knoll]

Am 08.08.2014 um 14:29 schrieb Bo Thorsen <bo at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140808/056b735b/attachment.html>