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