[Interest] Better Q_PROPERTY() ?

[Tomasz Siekierda]

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.

> 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