[Development] changing Q_GADGET

Rutledge Shawn Shawn.Rutledge at theqtcompany.com
Fri Nov 28 12:38:23 CET 2014


On 28 Nov 2014, at 12:19, Simon Hausmann <simon.hausmann at theqtcompany.com> wrote:

> Hi,
> 
> Monsieur Goffart did awesome work in the dev branch on allowing structures with 
> Q_GADGET to have properties and invokable methods. This brings the macro to a 
> much wider audience and I'd like to use this opportunity to propose a slight 
> change to it that may be controversial:
> 
> The macros Q_OBJECT and Q_GADGET both - towards the end of their definition - 
> change the member access permission level to "private". It's always been that 
> way.
> 
> I'd like to propose changing Q_GADGET to not change the access permission 
> level, so that you can write
> 
> struct MyStructure
> {
>    Q_PROPERTY(int x MEMBER x)
>    Q_GADGET
> 
>    int x;
> }
> 
> 
> I feel that Q_GADGET has its primary use with structures and the default 
> access level for those is public. I find it awkward that you currently have to 
> write:
> 
> structure MyStructure
> {
>    Q_PROPERTY(int x MEMBER X)
>    Q_GADGET
> public:
>    int x;
> }
> 
> 
> The proposed change would have two effects:
> 
> 1) It makes any existing code that _relies_ on Q_GADGET turning to private 
> suddenly expose members in structures.
> 
> 2) On paper it breaks binary compatibility with MSVC, in the unlikely event 
> that somebody 
>    a) produces a DLL and cares about binary compatibility
>    b) exposes bare structures
>    c) relies on Q_GADGET turning access permission levels to private
> 
> 
> I feel that the effects are negligible compared to the benefit of a better API.

Is it really only about the desire to avoid writing “public:” above the public data?  But on the other hand, if you wanted the data to be private you would probably have declared it that way, in either a class or a struct; so the convenience of having either macro make the default private is limited, right?

What are the right reasons to use structs instead of classes?  Is it only for the reason that members are public by default?

Why is Q_GADGET mainly used for structs and not classes?  Now that it has more features, maybe it could get used for some classes too.

Should we have public documentation for Q_GADGET?




More information about the Development mailing list