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

[André Somers]

On 18/03/2024 14:00, 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. 

Yes, such a design could have been used. But it was not, and it hasn't 
in many classes in Qt where overriding methods is part of the way to use 
it. I guess that could still be done, but not without a lot of pain. 
QAIM being a prime example. And I think there are also good reasons for 
that: it adds complication, another layer of indirection, another set of 
methods to document. To solve what problem exactly?

> 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. :-(

You act as if I didn't understand that, while I started out with saying 
"While I know it's easy to work around [...]". I *know* we can still 
call virtual methods that were public in the base class but have been 
made protected or private in a subclass by just downcasting that 
subclass instance to the base class. But it stands out in the user-code 
as doing something that was, while possible, not intended by the class 
designer. Fine by me.

But to me, that does not imply that I have to *advertise* that method on 
my public API in that subclass when it is re-implemented only for 
internal purposes, but you (and Marc) seem to be claiming that it should 
imply just that.


To go back to the original question: should QObject::event() be 
protected or public? I think it's right that it's public. It is called 
from outside the class itself by parts of Qt that deal with event 
handling, so it belongs on the public API for QObject. Had it been 
protected, we would have needed to use friend, and IMO that's worse: you 
cannot control _which_ private methods or members are touched that way.

So, in summary: I don't think we have a problem here. A public 
QObject::event advertises what it does, and it having been made 
protected in sub-classes is, IMO, not an actual problem.

Cheers,

André