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é
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
