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

[apoenitz]

On Mon, Mar 18, 2024 at 02:00:06PM +0100, Giuseppe D'Angelo via Development wrote:
> On 18/03/2024 13:34, André Somers wrote:
> > While I know it's easy to work around, I sometimes find myself doing it
> > anyway. To me, it signals what API is intended to be used in what way.
> > That a class overrides `event`  (or any other public virtual method)
> > does not mean that that method is then intended to be called by a user
> > of the class as the type you defined. That you overwrote it may just be
> > an implementation detail. I think the methods you expose as "public" on
> > an API are quite important*. They signal how the user is supposed to use
> > an instance of your class. If you have methods in there that are just
> > implementation details, then those don't fit. These methods are meant to
> > be called by parts of the system that don't see your type as the actual
> > type, but as something more basic: a QObject in this case.
> 
> But I agree 100% here; this is typically realized in C++ by having the entry
> point public and non-virtual, and have that dispatch to a protected virtual.

The "Non-virtual interface" pattern.

Been there, done that (in a different project), and sure, can be used and works.
But I wouldn't call it "typical", as it imposes overhead for practically no
gain even for new projects starting with that as the preferred approach, let
alone to setups where this "needs" to be introduced later.

> The whole problem we're discussing is that `event()` has been made public in
> the base class and that means it's now public API of any QObject subclass,
> whether they like it or not. :-(

The subclasses can (and often do) make it protected. This is a pragmatic
approach. It pretty much works and feels like NVI without having to write
the redirection at the base level.

Anyway, I would like to explicitly disgress here, as this is yet another
instance of a pattern I see repeating again and again, and while I (grudgingly)
accept that pragmatism is apparently not en vogue anymore, I still think there
should be a limit to that:

The actual problem here is /not/ whether or not QObject::event() should be
public/overridden in derived classes, or not, whether NVI is good or not, but
how much effort should be put into discussing and "solving" this kind of
ivory-tower (non-)problems, and how well such a "solution" would scale to "all
of Qt", instead of spending this energy and effort on fixing actual problems.

Andre'

PS: I had a quick look through the archive. There seems to be a pretty high
correlatation between threads with more than ~20 responses and what I personally
would call a "non-problem" to start with. Not 100%, but a good first approximation.

PPS: If someone has doubts on the claim of things being non-problems I heartily
invite them to come up with their own statistics on the actual effects of recent
changes in the string zoo.