> From: Development <development-boun...@qt-project.org> on behalf of Giuseppe > D'Angelo via Development <development@qt-project.org> > Sent: Friday, March 15, 2024 8:58 PM > To: development@qt-project.org > Subject: Re: [Development] Should QObject::event() be protected or public? > > Il 15/03/24 19:22, Giuseppe D'Angelo via Development ha scritto: >> Il 15/03/24 19:17, Jaroslaw Kobus via Development ha scritto: >>> +1. Typically, the designer of a subclass knows what he is doing. But it >>> also happens that users of this class know better how to use it :) >> I'm not sure what this means. >> >> If you override `event()` (public in QObject) as e.g. protected, it's >> either a mistake in good faith (you thought it was protected all along), >> but it's never a "I know better". You clearly*don't* know better, as >> you don't know C++. > > I'm really sorry, I just realized that this can be read in a very > offensive way: the "you" above was in *no* way directed to Jaroslaw > Kobus. It was a generic "you" -- as opposed as "I know better", for a > generic subject "I", not necessarily the writer. I apologize to > Jaroslaw if this caused a misunderstanding.
Don't worry, Peppe, I didn't take it personally, all is fine :) To the point: we are talking here about decreasing the visibility of a member function in a subclass. The virtuality of the method isn't relevant I guess, is it? I've never used it personally, but the fact that C++ language designers let it compile, even without a warning, makes me wonder that there were some reasons for it. Just found some reasoning, though not sure how much valid it is: https://www.learncpp.com/cpp-tutorial/hiding-inherited-functionality/ Probably there are more resources about this topic in the internet. Regards Jarek -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
