[Development] changing Q_GADGET

[Curtis Mitch]

> -----Original Message-----
> From: development-bounces+mitch.curtis=theqtcompany.com at qt-project.org
> [mailto:development-bounces+mitch.curtis=theqtcompany.com at qt-project.org]
> On Behalf Of Simon Hausmann
> Sent: Friday, 28 November 2014 12:20 PM
> To: development at qt-project.org
> Subject: [Development] changing Q_GADGET
> 
> 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.
> 
> What do you think?
> 
> 
> Simon
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

This sounds quite reasonable to me. I wasn't even aware of this behaviour, and would be quite worried if people were using these macros as access modifiers.