[Development] Request for early MOC support for C++20 Modules

[apoenitz]

On Fri, Dec 15, 2023 at 04:25:43PM +0000, Volker Hilsheimer via Development wrote:
> > On 15 Dec 2023, at 16:19, Sune Vuorela <nospam at vuorela.dk> wrote:
> >
> > On 2023-12-15, Elias Steurer via Development <development at qt-project.org> wrote:
> >> No, I still need all the get/set/notify functions to change/get the
> >> variables from the outside. There is currently no way to do that, or am
> >> I missing something? Something like this
> >> https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/ScreenPlayUtil/inc/public/ScreenPlayUtil/PropertyHelpers.h?ref_type=heads#L52
> >> but as a standardized Qt macro.
> >
> > My experience, after having written a few macros like that out of
> > projects, is that it is a bad idea, unless it is really thought thru.
> >
> > What I have seen is that it encourages all properties to be
> > read/write/notify where at least many of them was only supposed to be
> > read/notify or read/constant.
> >
> > /Sune
> 
> 
> Would it help/be a bad idea if moc would identify member functions that match the Qt naming convention so that you can reduce the boiler plate, e.g.
> 
> 
> class Thing
> {
> Q_PROPERTY(QString text)
> 
> public:
>     void setText(const QString &text); // obviously the setter
>     QString text() const; // evidently the getter
> 
> signals:
>    textChanged(const QString &text); // there’s a notification signal
> };
> 
> 
> Doesn’t help you if you use snake case, but *could* perhaps be configurable
> with a command line option.

Another option that could be considered in principle would be to try to get
away with less cases that need moc magic.

I haven't tried yet, but I have the gut feeling that one should be able
to get away with

    class Thing : public QObject
    {
        Q_OBJECT

    public:
        Property<QString> text; // getter and storage
        Setter<QString> setText{&text}; // setter

    signals:
        textChanged(const QString &text); // there’s a notification signal
    };

    Thing::Thing()
    {
        registerProperty(&text, "text");
    }

to provide essentially the same syntax on the user side, i.e.

    Thing t;
    QString s = t.text();
    t.setText("abc"); 

When going doen that road, also

    class Thing
    {
    public:
        Property<QString> text; // getter and storage
        Setter<QString> setText{&text}; // setter
        Signal<QString> textChanged{&setText};  // signal
    };

/might/ be possible. As I said, I haven't tried.

Andre'