[Interest] Better Q_PROPERTY() ?

[Jérôme Godbout]

I agree a much simpler macro Q_PROPERTY with a type and an argument name would be nice addition
Q_PROPERTY_RWN(proptype, arg)  -->  Q_PROPERTY(proptype  arg READ arg WRITE setArg NOTIFY argChanged)
R: for the READ part
W: for the write part
N: notify part
C: constant part

Would need to make all the derivated
Q_PROPERTY_RWN
Q_PROPERTY_RC
Q_PROPERTY_RN
...
That would stream line the naming for most value. Still can use the Q_PROPERTY() when something different come along.

For the getter/setter function could have a simple macro but this is tricky if you use pimpl or anything else. 
This seem more per people, but not too 

-----Original Message-----
From: Interest <interest-bounces at lists.qt-project.org> On Behalf Of Konstantin Tokarev
Sent: December 6, 2018 11:03 AM
To: Tomasz Siekierda <sierdzio at gmail.com>; sergio.martins at kdab.com
Cc: Interest at qt-project.org
Subject: Re: [Interest] Better Q_PROPERTY() ?



05.12.2018, 23:31, "Tomasz Siekierda" <sierdzio at gmail.com>:
> On Wed, 5 Dec 2018 at 18:23, Sérgio Martins via Interest 
> <interest at lists.qt-project.org> wrote:
>>  On 2018-12-05 16:41, Jason H wrote:
>>  > Epanding to:
>>  > private:
>>  > T _N;
>>  > public:
>>  > T N() { return _N; }
>>  > void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
>>  > signal:
>>  > void NChanged(T N);
>>  >
>>  > I know this might sound trivial but if I'm making 5 classes each 
>> with
>>  > 10 properties, that's 1500 lines of boilerplate code that I'm 
>> writing
>>  > (with code style applied).
>>  >
>>  > Is there any way to get closer to my ideal?
>>
>>  The problem with auto-generated setters is that sometimes you'll 
>> want to
>>  modify them to do additional stuff.
>
> Actually, I think this is not a problem at all if we keep current 
> Q_PROPERTY. Then, if you have some special case, you'd use Q_PROPERTY 
> and manually implement getters and setters. If you have a standard 
> case (like most of the
> time) you'd use
> the new declaration (like Q_PROPERTY_AUTO or whatever).
>
> You could say it's a bit similar to new and old connect() syntax. We 
> don't need to choose one - we can have both.

I'm strongly opposed to autogeneration of getters and setters, because this is far from being "standard case", except the most trivial situations, however it would be great if it was possible to avoid duplication of property name inside Q_PROPERTY for getter, setter and signal, and instead use naming convention (property, setProperty, propertyChanged)

>
>>  If you're using QtCreator then Q_PROPERTY will be auto-completed and 
>> you
>>  just need to write the property name.
>>
>>  Then, right click -> refactor -> "Generate missing Q_PROPERTY members".
>>  (which generates the member bodies in the header file unfortunately,
>>  https://bugreports.qt.io/browse/QTCREATORBUG-14622).
>>
>>  Maybe we need a "Qt language server", so all other editors would 
>> benefit
>>  from such refactorings.
>>
>>  Regards,
>>  --
>>  Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer
>>  Klarälvdalens Datakonsult AB, a KDAB Group company
>>  Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>>  KDAB - The Qt, C++ and OpenGL Experts
>>  _______________________________________________
>>  Interest mailing list
>>  Interest at lists.qt-project.org
>>  https://lists.qt-project.org/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> Interest at lists.qt-project.org
> https://lists.qt-project.org/listinfo/interest

--
Regards,
Konstantin

_______________________________________________
Interest mailing list
Interest at lists.qt-project.org
https://lists.qt-project.org/listinfo/interest