[Development] changing Q_GADGET
Al-Khanji Louai
louai.al-khanji at theqtcompany.com
Fri Nov 28 13:36:56 CET 2014
Out of the box, C++ makes class member declarations private. I quite strongly feel that changing that behavior in a macro is not what the user expects. So for me at least the "better API" box is not being checked here - I quite regularly declare private variables under Q_OBJECT and have done so with Q_GADGET as well.
-- Louai
> 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
More information about the Development
mailing list