On 14 Apr 2020, at 17:02, Matthew Woehlke
<mwoehlke.fl...@gmail.com<mailto:mwoehlke.fl...@gmail.com>> wrote:
On 14/04/2020 05.28, Lars Knoll wrote:
I believe there is mostly a consensus here to find a way to get rid
of those macros. But many of our users do seem to like the ‘emit’
keyword as an annotation to a signal emission, and it is being used
extensively in existing code bases.
You know what would solve this? The ability to define a *reflection* operator
(with proper name scoping) that could apply to statements and/or access
protection specifiers.
class MyObject
{
Qt::Q_OBJECT;
public Qt::slots:
...slots here...
};
MyObject::foo()
{
Qt::emit this->bar();
using namespace Qt;
emit this->bar();
none->emit(...); // *not* the Qt::emit operator
}
If we played this right, maybe we could even reimplement MOC using reflection?
(Stuff like Q_PROPERTY however might be hard, depending on if these operators
are allowed to take a *space* delimited list of arguments rather than comma
delimited.)
Maybe, but we can’t solve it with current C++ standards. I think we should
simply go and change the default for the QT_NO_KEYWORDS macro in Qt 6. Then,
it’s Q_SIGNALS, Q_SLOTS and Q_EMIT by default, and you’ll need to use a
#define to get them back: https://codereview.qt-project.org/c/qt/qtbase/+/297053
Cheers,
Lars
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
