[Interest] [Development] Qt 5 connect to static function: Suggestion for new overload.

[Björn Piltz]

Thiago, thanks for the patch! As you've noted in the comments to the patch
yourself, it doesn't quite work. I also would understand if you're
reluctant to add changes to such a central part of Qt. The new templated
connect already has a tendency to produce verbose and noisy error messages
if you mistype.

Olivier, I think your suggestion with addDeleteWatcher() is the most
precise. It would completely satisfy my original wish elegantly, without
requiring any radical changes:

QObject::connect(sender, &QLineEdit::editingFinished,
std::bind(&QWidget::setWindowModified, receiver,
true)).addDeleteWatcher(receiver);


Sorry about the XY thing, but at least you were completely able to
understand my intentions;)

Thanks for the suggestions.
Björn


2013/5/4 Olivier Goffart <olivier at woboq.com>

> > On sexta-feira, 3 de maio de 2013 11.50.14, Björn Piltz wrote:
> > > Would it be possible to add an overload of QObject::connect() like
> this:
> > >
> > > static QMetaObject::Connection connect(const QObject *sender,
> > > PointerToMemberFunction signal, const QObject *receiver, Functor
> > > functor);
> > >
> > > in addition to
> > >
> > > static QMetaObject::Connection connect(const QObject *sender,
> > > PointerToMemberFunction signal, Functor functor);
>
> Hi,
>
> I would say this is an instance of the XY problem:
> http://meta.stackoverflow.com/questions/66377/what-is-the-xy-problem
>
> Why would you want to have a 'receiver' when there is no really a receiver?
>
> Another question i often see is why don't we accept non-QObject receiver.
>
> Appart from being the object which owns the member function, the QObject
> receiver also get used for those features:
>  - The connection is automatically disconnected when the receiver is
> destroyed.
>  - The thread affinity of the object is used to possibly perform a queued
> connection in the thread of the receiver
>  - The receiver's sender() and senderSignalIndex() are updated.
>
> Those features are totally valid use case you may want for lambda
> functions,
> and I agree we should support that.  I had that in mind with several ways
> to
> solve it, but it was not implemented in Qt 5.0 because i left that for
> later.
>
> Here are some way to solve it:
>
> 1) add new overloads of QObject::connect with 5 arguments that takes
> functor
> as parametters with a receiver.
>
> Code would look like this:
>   connect(obj1, &Foo::theSignal,  obj2, [&]() { obj3->doSomething(obj2);
> });
>
> This is easy to do with C++11 variadic template,  a bit more difficult if
> you
> only have decltype and C++11 revisited SFINAE,  and even more difficult if
> you
> can't use C++11 at all.
>
> But here the problem is semantic. With a lambda function, we dont have a
> "receiver" anymore.  Also, why are we limited to one receiver?
>
>
> 2) Since we now return a QObject::Connection, we can add API on that class.
> For example:
>
>   auto c = connect(obj1, &Foo::theSignal, [&]() { obj3->doSomething(obj2);
> });
>   c.addDeleteWatcher(obj2);
>   c.addDeleteWatcher(obj3);
>   c.queueInThread(obj2.thread());
>
> Implementation of this would be trivial.
>
> Other syntaxes are possible:
>    connect(obj, ..., [&]() { ... } ).setReceiver(obj2);
>
> The challenge is thread safety. (what if the signal is emitted in another
> thread before we set the receiver?)
>
> 3) for deletion purpose, maybe having a kind of scoped pointer around
> QObject::Connection
>
>   obj2->m_connections.track(connect(obj1, ...,  [] {...} ));
>
> it could also be an API in QObject itself
>   obj2->trackConnection(connect(obj1, ...,  [] {...} ));
>
>
>
> I'm tempted to say that the new QObject::connect overloads are not that bad
> after all.
>
> --
> Olivier
>
> Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130506/c6c0275d/attachment.html>