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