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

[Scott Aron Bloom]

Has anyone brought up the property system that MOC provides as well?  Maybe I missed it...  

-----Original Message-----
From: interest-bounces+scott.bloom=onshorecs.com at qt-project.org [mailto:interest-bounces+scott.bloom=onshorecs.com at qt-project.org] On Behalf Of André Somers
Sent: Friday, December 28, 2012 12:29 AM
To: interest at qt-project.org
Subject: Re: [Interest] A suggestion about replacing signals, actions and slots

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é

_______________________________________________
Interest mailing list
Interest at qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest