[Development] Should QObject::event() be protected or public?

[Giuseppe D'Angelo]

Il 15/03/24 21:21, Jaroslaw Kobus via Development ha scritto:
> To the point: we are talking here about decreasing the visibility of a
> member function in a subclass.
> The virtuality of the method isn't relevant I guess, is it?

It is relevant, since that's the whole problem: since event() is a 
virtual which is public in QObject, it's pointless to restrict it 
further in a subclass, because you can always place the call considering 
the object as-a QObject (=> upcast it) and bypass the restriction.

Therefore, when one creates a QObject subclass with an event() override, 
then:

* either they didn't know about the fact that it was public in QObject, 
and thought it was protected/private (because virtual functions should 
normally be protected), without think about the above C++ """feature""" 
at all, etc. (mistake in good faith);

* or they were *deliberately* trying to change the access level, i.e. 
trying to *outsmart* C++, but that goes nowhere; making it more 
restrictive simply doesn't work (can be bypassed by upcasting, breaks 
generic code that codes against the interface, breaks subclasses).



> I've never used it personally, but the fact that C++ language designers
> let it compile, even without a warning, makes me wonder that there were
> some reasons for it.

C++ has also 30? 40? years of crust. Why does C++ even allow different 
accessibility levels for different overrides to begin with?

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240318/045882ab/attachment.bin>