[Interest] A suggestion about replacing signals, actions and slots

[André Somers]

Replying via the ML instead of directly as you did to me:

Op 27-12-2012 17:20, Oleg Yarigin schreef:
>> 3rd, Qt's signals and slots do a lot more than a vanilla function
>> pointer will ever do. Or can that transparently handle threading? Queued
>> connections, blocking if needed? Type safety? Provide information on who
>> triggered the signal? Work with mis-matched argument lists? Work with
>> signal-signal connections? Provide many-to-many relationships between
>> the caller (signal) and the callee (slot)? Signals & slots do provide
>> all that.
>> And yes, that includes lambda functions. Second, moc and Q_OBJECT does a
>> good deal more than just dealing with signals and slots.
> Thanks a lot for explanation and criticism - i did not know about that!
>
>
>> You clearly have no clue what you're talking about.
> You are right, there is no such simple solution as I though before.
Well, if you have little or no knowledge on what signals & slots really 
*are*, why do you keep insisting that they are a problem and keep 
throwing about ill-researched proposals for 'solutions' to these 
imagined problems?

> How do you think about defining all signals/callbacks as copies of QSignal delegate class? This class must provide:
> 1. Template header for setting signal`s prototype.
> 2. Overloaded "=" operator for adding callback references to list. References point to methods of classes.
> 3. Control for destroying objects that contain connected callback functions.
> 4. "emit()" function for calling all connected callback functions from the list.
Again: what is the benefit? What does it solve? What drawbacks does it have?

>> Or can that transparently handle threading?
> Um, an application memory is shared between all its threads, is not it? So callback pointers are global for all threads.
Yes. And that's a problem, because you end up with different threads 
calling code in the same instance of an object, wreaking havoc if you're 
not very, very careful. The trick is not calling random functions from 
within a thread, the trick is to manage to make an event (signal emit) 
in one thread result in code being executed in *another* thread (slot). 
Callback pointers are not going to provide you that natively. It will 
take a lot of machinery, exactly as Qt is already providing you...

>> Queued connections, blocking if needed?
> I hope, my QSignal can do it in emit() function.
*HOW*? This is not about magic... And how would your implementation be 
better than the one we're already using for years?

>> Work with mis-matched argument lists?
> Maybe define all arguments for such functions as optional ones?
Optional arguments already work, also with slots. The trick is being 
able to connect a signal that has one or more arguments to a slot that 
doesn't.

>> Provide many-to-many relationships between the caller (signal) and the callee (slot)?
> A slot list inside QSignal and adding function into many QSignal objects?
Ah. So another reimplementation of the Observer pattern? How do you 
think this is handled now? You know what: don't guess, simply read the 
source code. It is right there for you to study.

> Yes, I understand that it is very complicated, and it worked well for a very long time; besides, I _don`t_ say that we must to change it just now.
So, what *are* you proposing then? You barge in claiming that 
signal/slot is a problem that needs to be solved somehow.  If it really 
is an urgent problem, it needs to be solved quickly, right? And if it is 
not a problem, then why does it need solving at all?

I'd like to recommend you that you try to first actually implement 
something similar to what you are after (perhaps in a somewhat 
simplified version), so you get to understand what is actually involved 
in building something as convenient as signal/slots. And then see how it 
compares API wise to what Qt is already offering.

André