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

[Edward Welbourne]

Giuseppe D'Angelo (18 March 2024 12:12)
> 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).

Or they could be thinking: "surely that *should* be protected in QObject,
so I'll make it protected in my derived class so that *when* someone
gets round to (at a major version change) making QObject::event()
protected, this overload shall be ready-protected in support of that."
Whether that's a good plan or not is another story, but it's another
possible motive.

	Eddy.