> On 28 Feb 2020, at 21:18, Sérgio Martins via Development > <development@qt-project.org> wrote: > > On 2020-02-28 18:32, Thiago Macieira wrote: >> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >>> If we had to do it over again, it might make sense to follow Python and >>> make signals *objects* instead of *methods*. Then the code would look like: >>> this->emptied.emit(...); >> Binary compatibility issue: if it's a member of the class, it can't be added >> or removed without changing the class's size and layout, so it would tie our >> hands for future improvements. >> You'd see instead: >> this->emptied().emit(...); >> connect(foo, foo->emptied(), ...); > > > I like this, then we could finally (and without hacks) have protected and > private signals like in Qt 4. > > Would also solve the need for qOverload ?
This is all nice and fun to bike shed about, but I don’t think those proposed solutions match the scope of the original problem (which was relatively small). I don’t think a massive source compatibility breakage is what we want, just because there is one std header using emit as a method name. And most of Qt’s signals are named in a way that makes it rather obvious it’s a signal we’re looking at (e.g. fooChanged() or clicked()), so there’s no need for an ‘emit’ in front to be clear. Some names are less obvious and the ‘emit’ does help readability of our source code. So to shortcut this discussion a bit: I am completely opposed to a massive SIC changes/efforts for our signals (like giving them ugly names like emitClicked(), or signal objects). If people feel strongly, I am open to trying to find a way to keep some sort of ‘emit’ prefix (whether that’s Q_EMIT or a [[qt::emit]] attribute), but I do agree with Marc that we should in the long term try to get away from having emit/signals/slots defined as macros (at least by default). Cheers, Lars _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
