Hi Ivan,
On 10.11.22 11:03, Ivan Solovev via Development wrote:
> I wonder how your NOI-everywhere suggestion will work with the
> signal/slot connections? Specially for the case when
> Qt::QueuedConnection is used (explicitly or implicitly).
That's a very good question, thanks.
As a first reaction, three things come to mind:
1. It doesn't, obviously. If you emit signals, any signal argument must
be owning, or QueuedConnection cannot be used. Given that C++20
requires us to mark up views and non-owning ranges (enable_view,
enable_borrowed_range), I'm confident that we could detect attempts
to create such connections at compile- or, latest, at run-time, and
refuse them, or, since we need to serialize the arguments into a
QMetaCallEvent, anyway, also lifetime-pin, either by holding a weak
reference to the source object or by storing the data in the event in
an owning container.
2. QML and QProperty do not appear to require passing the new value in a
NOTIFY signals's parameter, so just not passing the argument is an
option, too (but doesn't work with QueuedConnection, either).
3. Finally, the kinds of types I'm primarily thinking of in the context
of NOI are not Q_OBJECTS. It remains to be seen in which form or
shape co-routine-based reactive programming will complement or even
substitute signal/slots in the future.
So, to summarize, I'd say that NOI works well with signal/slot, too,
with the exception of QueuedConnection, where we have several options
for work-arounds.
But this is definitely something we need to keep in mind, going forward,
indeed.
Thanks,
Marc
--
Marc Mutz <marc.m...@qt.io>
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
