Re: [Development] Should QObject::event() be protected or public?
On Fri, Mar 15, 2024 at 10:48 PM Marc Mutz via Development <
development@qt-project.org> wrote:
> The member variable thing sounds very wrong. I'd be surprised if it
> compiled.
Then you'd be surprised.
> If it does, it's probably something new in C++23 or 26 whereby
> you can use `using` for more general renaming [...]
If I'm not mistaken it's a C++17 feature. You can also use this to 'pull'
specific methods out of specific bases (e.g. if there's a name
clash/ambiguity), not only for changing access scope.
E.g.
struct A
{
int foo(int);
};
struct B
{
double foo(double);
};
struct C : A, B
{
using A::foo;
using B::foo;
};
Which allows C to have `foo()` properly overloaded.
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On 15.03.24 21:21, Jaroslaw Kobus via Development wrote:
[...]
> 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.
That page doesn't look very trustworthy.
The first example is valid. One can make something public that was
protected in a base class, because it doesn't violate Liskov's
Substitution Principle: One can still do everything one can do with the
base class with the derived class, too. One can just do more with the
derived class, which is pretty common (one can get text() from a
QLineEdit, but not from a QWidget (well, except via its Q_PROPERTY)).
The member variable thing sounds very wrong. I'd be surprised if it
compiled. If it does, it's probably something new in C++23 or 26 whereby
you can use `using` for more general renaming, like
struct insert_result {
iterator it;
bool inserted;
using first = it; // was std::pair before, keep .first working
using second = inserted;
};
I saw a proposal for that floating around some time ago, but don't know
the status of it.
In general, just because C++ lets one do something doesn't mean it's a
good idea. Apart from the C ballast, C++ itself is a language with a
huge design-space, and four decades of cruft. Only very few planes in
that design space make sense in general, they change with each C++
version, and even fewer of them make sense in any given project context.
There's a reason why CppCoreGuidelines are so huge and why TTLOFIR is
growing so rapidly: C++ projects need hundreds or thousands of rules to
tailor C++'s vast design space to something that's acceptable for the
project. Do the work, or die from technical debt. The core of Qt
(qt.git) is pretty consistent, still, but we have dozens of modules, and
hundreds of contributors now of extremely varying experience, and C++
has evolved a lot since C++98, so I think we need to codify a lot more
stuff than we have done in the past (and, where possible, have tools
check it). Look at all the google-specific checks in clang-tidy for example.
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
> From: Development on behalf of Giuseppe > D'Angelo via Development > 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
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. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On 15/3/24 19:57, Jean-Michaël Celerier wrote: There's nothing more frustrating that instantiating a C++ type on the stack like MyType foo; and having to call a function with: static_cast(foo).someVirtualMethod(); Or: foo.Base::someVirtualMethod(); [..] -- Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
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++. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
> From: Development on behalf of Thiago > Macieira > Sent: Friday, March 15, 2024 7:03 PM > To: development@qt-project.org > Subject: Re: [Development] Should QObject::event() be protected or public? > > On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote: >> I like simple rules. "Overrides should have the same access level as the >> initial virtual function." is a simple rule. > > Amend that to "... unless there's an explicit reason not to". With that, I'm > ok. As you can still access by casting to a base, that had better be a good > reason. +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 :) Jarek -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On Friday, 15 March 2024 11:03:19 PDT Thiago Macieira wrote: > On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote: > > I like simple rules. "Overrides should have the same access level as the > > initial virtual function." is a simple rule. > > Amend that to "... unless there's an explicit reason not to". With that, I'm > ok. As you can still access by casting to a base, that had better be a good > reason. Which actually points to a reason why you'd do it: to make it *more* accessible (make public, or make a private become protected). -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote: > I like simple rules. "Overrides should have the same access level as the > initial virtual function." is a simple rule. Amend that to "... unless there's an explicit reason not to". With that, I'm ok. As you can still access by casting to a base, that had better be a good reason. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
There's nothing more frustrating that instantiating a C++ type on the stack like MyType foo; and having to call a function with: static_cast(foo).someVirtualMethod(); because "The base class is the interface" and all the overriding methods are marked private. This is just adding bureaucracy for absolutely no good reason and doesn't help *anyone*. On Fri, Mar 15, 2024 at 1:32 PM Christian Kandeler via Development < development@qt-project.org> wrote: > On 3/15/24 18:09, Marc Mutz via Development wrote: > > I like simple rules. "Overrides should have the same access level as the > > initial virtual function." is a simple rule. > > But it makes no sense in general. The base class is the interface, and > overrides should have the least possible visibility for their purpose. > > > Christian > > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On 15.03.24 18:31, Christian Kandeler via Development wrote: > On 3/15/24 18:09, Marc Mutz via Development wrote: >> I like simple rules. "Overrides should have the same access level as the >> initial virtual function." is a simple rule. > > But it makes no sense in general. The base class is the interface, and > overrides should have the least possible visibility for their purpose. Let me turn that around and ask you to explain why the specific static type should matter when calling a virtual function: MyWidget *myw = new MyWidget; // ¹ QWidget *id = myw; QObject *obj = wid; obj->event(e); // OK wid->event(e); // ERROR: protected myw-.event(e); // OK, public again "Normal" functions never behave that way. Why should virtual functions behave so erratically? Users look at the QObject docs, see that there's a public event() function and for some reason decide that's the function to call. QWidget is-a QObject, so by the Liskov Substitution Principle, you should be able to do anything to a QWidget than you can do to a QObject. So why can't I call event() on it? ¹ from src/corelib/doc/snippets/events/events.cpp (iow: our docs) Thanks, Marc -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On 3/15/24 18:09, Marc Mutz via Development wrote: I like simple rules. "Overrides should have the same access level as the initial virtual function." is a simple rule. But it makes no sense in general. The base class is the interface, and overrides should have the least possible visibility for their purpose. Christian -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On 15.03.24 14:28, Volker Hilsheimer via Development wrote:
>> On 15 Mar 2024, at 12:30, Marc Mutz via Development
>> wrote:
>> On 15.03.24 09:11, apoenitz wrote:
>>> On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote:
>> [...]
Please note that this means that any override (and all new QObject
classes should contain one, since, in case we ever need it, it might not
be possible to add it after the fact) should also be public.
>>>
>>> Neither is a necessary consequence, and I don't think this new rule
>>> would be helpful.
>>
>> I have explained this here and over in TTLOFIR. If people choose to not
>> read, or, if read, choose not to understand, or, if understood, choose
>> to not accept, there's nothing more that I can do.
>
> I have read, but not understood, what or where “TTLOFIR” is.
Don't worry, I'll repeat TTLOFIR until the last Qt developer knows the
acronym: https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews :)
>>> What kind of setups do you expect where an event() override in the
>>> middle of the inheritance chain needs to be called from outside to
>>> warrant this rule requiring class-implementor to regularly write code
>>> that's unlikely (and I claim: Never) needed?
>>
>> It's not my job to argue why we should keep breaking a very general C++
>> rule, one most C++ developers probably don't know _can_ be broken, but
>> I'll throw you a bone: qcompleter.cpp
>
> That there exists code that calls QObject::event directly, whether because it
> can (and the author didn’t know about QCoreApplication::sendEvent), or
> because it has to (to avoid recursion when using sendEvent), doesn’t make it
> any less of a smell.
>
> And we evidently need to have a public QObject::event so that code that must
> call it (for whatever reason) has a way to do so. Some smells have valid
> reasons to exist, and making them visible in code by requiring
>
> (static_cast(d->widget))->event(ke);
>
> (unnecessary parenthesis presumably not required for it to raise eyebrows in
> code review) is a good thing.
>
> But I still don’t see a reason why we now need to start arguing about a
> pattern that has been used in Qt quite consistently for 30 years, i.e. making
> overrides of event handlers, including QObject::event and
> QObject::eventFilter, protected.
>
> Volker
>
> PS: and indeed, just that something has been done for 30 years is not an
> argument in itself; that it’s a pattern that has worked, has been accepted,
> and has prevented mistakes however is.
I like simple rules. "Overrides should have the same access level as the
initial virtual function." is a simple rule. Clang-tidy probably has a
checker for that already, but if not, it's trivially written. Qt is very
large, if there's tooling that we can use to encode rules, then that's
what we should be doing, IMHO. Esp. now that TQtC owns Axivion.
Speaking from API-review experience here.
But, yes, by majority vote, in Qt we currently have "Overrides are
generally the same access level as the initial virtual function, unless
the developer didn't pay attention, didn't care (we have private API
where everything is public e.g.) or unless the function is
QObject::event() or QObject::eventFilter(), in which case
reimplementations should be protected to make code calling the function
on derived classes uglier. Check back often, in case we find more
exceptions."
Clang-tidy/Axivion for sure don't have a check for that, and it's not
quite so trivial to implement.
So, back to QObject::event() as protected function. Should we then add
non-virtual QObject::process/filterEvent(QEvent*) (to be bikeshed) that
call protected event()/eventFilter()?
Thanks,
Marc
PS: Should we finally lift the restriction that event filters must be
QObject's? Could have been
class QEventFilter {
virtual ~QEventFilter();
virtual bool filter(QObject *o, QVent *e) const = 0;
};
Or, these days, std::function (except that
std::function is horrible)?
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Let's drop MSVC 2019 for dev (6.8)
On Monday, 5 February 2024 01:44:29 PDT Allan Sandfeld Jensen wrote: > I was trying to drop support for it in qtwebengine in 6.7, but the problem > was it was still used for qt packaging. But if we could at least switch > packing to vs2022, it would mean we could drop it in QWE. Can we commit to this ASAP after the 6.7 release? We'll revisit later in the cycle whether we still need 2019. Do note that Microsoft is preparing the next release after 2022, as seen by their shipping 17.0 Tech Previews. Jörg accidentally broke the C++ language level set up in dev, meaning we didn't test C++20 mode with 2019 for a day or so, and some changes that trigger 2019's broken C++20 support went in. If we don't drop 2019 by 6.8 release, we should force it to only compile in C++17 mode. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
> On 15 Mar 2024, at 12:30, Marc Mutz via Development > wrote: > On 15.03.24 09:11, apoenitz wrote: >> On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote: > [...] >>> Please note that this means that any override (and all new QObject >>> classes should contain one, since, in case we ever need it, it might not >>> be possible to add it after the fact) should also be public. >> >> Neither is a necessary consequence, and I don't think this new rule >> would be helpful. > > I have explained this here and over in TTLOFIR. If people choose to not > read, or, if read, choose not to understand, or, if understood, choose > to not accept, there's nothing more that I can do. I have read, but not understood, what or where “TTLOFIR” is. >> What kind of setups do you expect where an event() override in the >> middle of the inheritance chain needs to be called from outside to >> warrant this rule requiring class-implementor to regularly write code >> that's unlikely (and I claim: Never) needed? > > It's not my job to argue why we should keep breaking a very general C++ > rule, one most C++ developers probably don't know _can_ be broken, but > I'll throw you a bone: qcompleter.cpp That there exists code that calls QObject::event directly, whether because it can (and the author didn’t know about QCoreApplication::sendEvent), or because it has to (to avoid recursion when using sendEvent), doesn’t make it any less of a smell. And we evidently need to have a public QObject::event so that code that must call it (for whatever reason) has a way to do so. Some smells have valid reasons to exist, and making them visible in code by requiring (static_cast(d->widget))->event(ke); (unnecessary parenthesis presumably not required for it to raise eyebrows in code review) is a good thing. But I still don’t see a reason why we now need to start arguing about a pattern that has been used in Qt quite consistently for 30 years, i.e. making overrides of event handlers, including QObject::event and QObject::eventFilter, protected. Volker PS: and indeed, just that something has been done for 30 years is not an argument in itself; that it’s a pattern that has worked, has been accepted, and has prevented mistakes however is. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On 15.03.24 09:11, apoenitz wrote: > On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote: [...] >> Please note that this means that any override (and all new QObject >> classes should contain one, since, in case we ever need it, it might not >> be possible to add it after the fact) should also be public. > > Neither is a necessary consequence, and I don't think this new rule > would be helpful. I have explained this here and over in TTLOFIR. If people choose to not read, or, if read, choose not to understand, or, if understood, choose to not accept, there's nothing more that I can do. > What kind of setups do you expect where an event() override in the > middle of the inheritance chain needs to be called from outside to > warrant this rule requiring class-implementor to regularly write code > that's unlikely (and I claim: Never) needed? It's not my job to argue why we should keep breaking a very general C++ rule, one most C++ developers probably don't know _can_ be broken, but I'll throw you a bone: qcompleter.cpp Thanks, Marc -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote: > Summary as of 2024-3-14 EOD: QObject::event() has to stay public. Ok. > Please note that this means that any override (and all new QObject > classes should contain one, since, in case we ever need it, it might not > be possible to add it after the fact) should also be public. Neither is a necessary consequence, and I don't think this new rule would be helpful. What kind of setups do you expect where an event() override in the middle of the inheritance chain needs to be called from outside to warrant this rule requiring class-implementor to regularly write code that's unlikely (and I claim: Never) needed? Please note that this thread was started with the assumption that not even the base QObject::event() needs to be callable from the outside, [and also that, in principle, for truly hard cases, one can legally sneak out of the 'protected' jail via litb's trick using ISO/EIC 14882:2011 14.7.2(12)] Andre' > Thanks, > Marc > > On 13.03.24 08:58, Marc Mutz via Development wrote: > > Hi, > > > > In API review, we detected some overrides that changed the access > > specifier vis-a-vis the original virtual function > > (https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Polymorphic_Classes > > Item 5.3). > > > > One of them was a protected reimplementation of QObject::event() (which > > itself is public). > > > > The reason why QObject::event() is public seems lost to history, but the > > feeling in the review comments¹ was that it should have been protected > > from the get-go (and QObject befriended by whoever delivers events). > > > > If you see any reason for QObject::event() to stay public in Qt 7 and > > not become protected, please speak up before we fork Qt 7.0 :) > > > > Thanks, > > Marc > > > > ¹ > > https://codereview.qt-project.org/c/qt/qtdeclarative/+/528290/comment/f51938ca_fd065a18/ > > > -- > Marc Mutz > Principal Software Engineer > > The Qt Company > Erich-Thilo-Str. 10 12489 > Berlin, Germany > www.qt.io > > Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen > Sitz der Gesellschaft: Berlin, > Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Jøger Hansegård for approver rights
+1 From: Development on behalf of Tor Arne Vestbø via Development Sent: Thursday, March 14, 2024 10:06 To: development Subject: [Development] Nominating Jøger Hansegård for approver rights Hi, I would like to nominate Jøger Hansegård for approver rights in the Qt project. Jøger joined The Qt Company 10 months ago and has since then been getting his hands dirty in Qt Multimedia, and lately focusing on color management. Jøger is a thorough and responsible engineer and I trust that he will make a good approver for the Qt project. Authored changes: https://codereview.qt-project.org/q/owner:joger.hansegard%2540qt.io Reviews: https://codereview.qt-project.org/q/reviewer:joger.hansegard%2540qt.io Cheers, Tor Arne -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Jøger Hansegård for approver rights
+1! Lars > On 14 Mar 2024, at 10:06, Tor Arne Vestbø via Development > wrote: > > Hi, > > I would like to nominate Jøger Hansegård for approver rights in the Qt > project. > > Jøger joined The Qt Company 10 months ago and has since then been getting his > hands dirty in Qt Multimedia, and lately focusing on color management. > > Jøger is a thorough and responsible engineer and I trust that he will make a > good approver for the Qt project. > > Authored changes: > https://codereview.qt-project.org/q/owner:joger.hansegard%2540qt.io > Reviews: > https://codereview.qt-project.org/q/reviewer:joger.hansegard%2540qt.io > > Cheers, > Tor Arne > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
Summary as of 2024-3-14 EOD: QObject::event() has to stay public. Please note that this means that any override (and all new QObject classes should contain one, since, in case we ever need it, it might not be possible to add it after the fact) should also be public. Thanks, Marc On 13.03.24 08:58, Marc Mutz via Development wrote: > Hi, > > In API review, we detected some overrides that changed the access > specifier vis-a-vis the original virtual function > (https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Polymorphic_Classes > Item 5.3). > > One of them was a protected reimplementation of QObject::event() (which > itself is public). > > The reason why QObject::event() is public seems lost to history, but the > feeling in the review comments¹ was that it should have been protected > from the get-go (and QObject befriended by whoever delivers events). > > If you see any reason for QObject::event() to stay public in Qt 7 and > not become protected, please speak up before we fork Qt 7.0 :) > > Thanks, > Marc > > ¹ > https://codereview.qt-project.org/c/qt/qtdeclarative/+/528290/comment/f51938ca_fd065a18/ > -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
