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
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
To add a user perspective to the discussion: Please keep things simple and
consistent. Consistency is great, especially in large code bases.
Changing access modifiers for an existing interface in a derived class is
confusing. Due to the way the documentation is structured, it’s also hard to
On 18 Mar 2024, at 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
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
Hey,
On 18/03/2024 12:12, Giuseppe D'Angelo via Development wrote:
Il 15/03/24 21:21, Jaroslaw Kobus via Development ha scritto:
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?
Giuseppe D'Angelo (18 March 2024 12:12)
> Therefore, when one creates a QObject subclass with an event()
> override, then:
>
> * either they didn't know about the fact that it was public in
> QObject, and thought it was protected/private (because virtual
> functions should normally be
Il 15/03/24 21:21, Jaroslaw Kobus via Development ha scritto:
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?
It is relevant, since that's the whole problem: since event() is a
On Sat, Mar 16, 2024 at 4:01 PM Marc Mutz via Development <
development@qt-project.org> wrote:
> Function != variable ;-)
>
Granted, they're different and using declarations are intended for and work
for _both_ functions and variables.
I was simply providing some context where this syntax is
On 16.03.24 01:47, Konstantin Shegunov wrote:
> On Fri, Mar 15, 2024 at 10:48 PM Marc Mutz via Development
> mailto:development@qt-project.org>> wrote:
>
> The member variable thing sounds very wrong. I'd be surprised if it
> compiled.
[...]
> struct A
> {
>
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
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
> 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
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
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
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.
> 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 wr
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
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
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
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
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
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
> 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,
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
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
>
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
On Wed, 13 Mar 2024 07:58:20 +
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).
>
>
:58 AM
To: development@qt-project.org
Subject: [Development] Should QObject::event() be protected or public?
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
Il 13/03/24 08:58, Marc Mutz via Development ha scritto:
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 :)
I am *positive* that there's code out there that just calls event() to
deliver an event.
(Maybe
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
31 matches
Mail list logo
