[Development] QWebEnginePage and Qt 6: protected virtual functions and signals

[Benjamin TERRIER]

On Thu, 27 May 2021 at 14:17, Allan Sandfeld Jensen <kde at carewolf.com>
wrote:

> On Donnerstag, 27. Mai 2021 13:55:01 CEST Benjamin TERRIER wrote:
> > On Thu, 27 May 2021 at 11:25, Allan Sandfeld Jensen <kde at carewolf.com>
> >
> > But then in my code, each time I see a CrazySSLPage I am never sure that
> it
> > will ignore SSL errors. Maybe someone called QObject::disconnect() on it.
> >
> > CrazySSLPage page;
> > page.disconnect(); // It's just a QWebEnginePage now
>
> If you call disconnect on a QWebEnginePage (or most advanced Qt classes)
> you
> have bigger problems than that, we rely on that for internal stuff too. As
> a
> C++ toolkit we can not protect users from doing bad things, it is always
> in
> their power.
>

Then maybe a warning  should be added to:
https://doc.qt.io/qt-5/qobject.html#disconnect-2

But it does not change my point about signal vs protected functions.
Let's say I have a QWebEnginePage subclass that only allows some SSL errors
by checking asynchronously a blocked list (using the defer() function of
the QWebEngineCertificateError)
External code can connect to the signal and ignore/block the error before
the async check has completed, breaking the behavior of the subclass.

IMHO using signals to implement the class behavior breaks encapsulation.
The behavior that was protected and defined in the class, is now defined
outside of the class and is publicly available to be overridden.
Signals are not a replacement for virtual protected functions.

I have a strong feeling that moving signals, without having the ability to
block signals by implementing protected functions, will lead to brittle
code for Qt users.
The worse part, is that right now it is possible in user code to
implement a SignalWebEnginePage, that will expose its protected functions
as signals.
After moving to signals, it won't be possible to not expose them. With this
change, as-is, Qt users are losing features, for some convenience that they
could implement themselves with a few lines of code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210527/5be93757/attachment-0001.html>