[Development] [RFC] What to do about overloaded signals/slots?

[Grégoire Barbier]

Le 05/10/2013 18:24, Olivier Goffart a écrit :
(...)
> As you may or may not know, it is a bit tricky to use the pointer based
> connection syntax with overloaded signals or slot.
>
> If you do, say:
>
>   connect(process, &QProcess::error;
>       this , &MyObject::processError);
>
> You get a compilation error looking like this
>
>   error:   no matching function for call to 'QObject::connect(QProcess*,
>          <unresolved overloaded function type>, ...
>
> Because QProcess::error is overloaded and the compiler can detect its type.
>
> They way around is to manually specify the type.  This is a bit difficult, and
> many developers get problem with it. Which is why I made a patch to qdoc to
> always show an example.
(...)
> I would also like to remind that adding overloads to functions is not
> source compatible,  as it may break a connection using the function
> pointer syntax.
> Overloaded signals and slots should be avoided.
(...)

Hi,

I'm currently porting for the first time a Qt4 app to Qt5 and meanwhile 
discovering new great Qt5 features, therefore I'm far from beeing an expert.

However my current opinion about Qt5 new connect syntaxes is that the 
one with functor is great¹ but the one with pointers to members, even 
though being nicer to read since we all dislike using macros, is in fact 
dangerous since not only hard to use (as you state many developers are 
not at ease with finding which class to prefix with) but also hard to 
maintain because e.g.
(i) code reingeniering (remember that slots are not only defined in Qt 
framework classes but also in casual application code which is less 
stable) such as moving a slot from a class to its parent would break 
connections, and
(ii) slot overloading change in a parent class is undetectable and will 
missconduct signals to undesired slot method.

With macros these issues did not happen because meta object mechanisms 
support them through the characters string signature, which even support 
slots overloading in a convenient fashion (i.e. by preserving source 
compatibility even when overloading a slot method).

In addition, I find slot overloading usefull, more precisely I find 
convenient to define a slot in a parent class on a virtual method and to 
overload it in relevant child classes without worrying with slot anymore.
I say slot because you wanted to talk about slots but I do the same with 
non-slot Q_INVOKABLE methods when handling multithread invocations 
without signals or connections (through raw invokeMethod() calls).

Finally, even though I find SIGNAL() and SLOT() macros not so beautifull 
than pointers to members, frankly, QtCreator does the completion so well 
and so painless that I forgot that there were macros in connect call 
until I read Qt5 release notes...

Therefore, if I were a Qt project developer, not only I would not 
deprecate slot overloading, but if I were to choose between slot 
overloading and pointers to members connect, I would deprecate pointers 
to members connect.
However I'm not a Qt project developer. And I may be wrong.
And I know that calling for deprecating a brand new feature is somewhat 
heretic. Please don't burn me alive.

Regards.

¹: especially with lambdas as soon as I will be able to afford being 
tight to C++11, which I'm not yet because of all that old linux distro 
with old gcc versions
-- 
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49