[Development] changing Q_GADGET

[Milian Wolff]

On Friday 28 November 2014 12:41:47 Olivier Goffart wrote:
> On Friday 28 November 2014 12:19:45 Simon Hausmann 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.
> > 
> > What do you think?
> 
> I have several times been bitten by the same problem when i used Q_OBJECT in
> a struct.
> But when I weight the pro and the cons, i'm not sure if it's a good idea.
> 
> Pros:
>  + Save one line when declaring a Q_GADGET in a struct
> 
> Cons:
>  - The change may change some member (data or function) from private to
> public - Is inconsistent with Q_OBJECT (and both are usually used in class)
> - Something that is incorrectly set as private will result in compilation
> errors that will be easily spotted and fixed. Something inadvertently left
> public will stay unnoticed until it's too late to change it.
> 
> Notice that in our code we recommend to always use class and almost never
> struct.  All the Q_GADGET today are class.
> 
> An alternative to save that line might also be to put the Q_GADGET macro at
> the end of the struct.

Why don't you just introduce a new macro?

Bye

-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions