Add automatic FINAL detection to W_PROPERTY

[jcelerier]

I don't know if it's the correct way to do it (and what the exact effects of FINAL properties are, the doc doesn't really precises it) but in any case here it is

[CLAassistant]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

:white_check_mark: jcelerier
:x: ogoffart
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[ogoffart]

This is interresting. thanks for the patch.

Can you add a test in tests/basic/tst_basic.cpp. You can add a final class and check its property are final.

[ogoffart]

I wonder if it is this patch which cause this MSVC internal compilation error on AppVeyor.

[jcelerier]

I don't think so, appveyor recently upgraded to VS 15.7 which does not work (#36) ; for my own projects I fixed by changing to image: Previous Visual Studio 2017 in appveyor.yml

[ogoffart]

Thanks again for the contribution.

But thinking more about it, I am not sure this is a good thing anymore. If you consider QML, you can still "override" final C++ QObject from QML. And you can in QML override their properties. So this would be a change compared to the "normal" Qt Is this something we want to change?

The FINAL does not have so much impact on the code. It is only used on QML to throw an error if you override the property AFAIK. There is no performance implication in the current QML. (There used to be one in QtQuick 1)

[jcelerier]

If you consider QML, you can still "override" final C++ QObject from QML.

I think that this case cannot happen : since the C++ class is marked as final, it cannot be registered in the QML type system anyways since qmlRegisterType calls QQmlPrivate::createInto<T> which itself declares a new type (side-note : this one could certainly be marked final, maybe this could help GCC or Clang in case of a big LTO ? )

 template<typename T>
 class QQmlElement : public T { };

which will not compile. Are there other cases ? Of course if it's only improving stuff in Qt Quick 1, it's relatively useless :p (the doc said This can be used for performance optimizations in some cases, but is not enforced by moc. which made me hope for nicer things).

[ogoffart]

So in summary, this patch is not so useful since:

• Final classes can't be registered in QML, where the property system is the most useful
• The final attribute is currently unused within Qt anyway.

Yet, the patch looks good to me and I will then merge it.

[ogoffart]

(Merged)

[jcelerier]

Final classes can't be registered in QML, where the property system is the most useful

do you know if there is a reason for the current qml object registration mechanism to work like it does (by subclassing with an "empty" class?)

The final attribute is currently unused within Qt anyway.

would there be some optimization opportunities in QtCore about this or not at all ?

[ogoffart]

do you know if there is a reason for the current qml object registration mechanism to work like it does (by subclassing with an "empty" class?)

Actually, you can return any QObject* or Q_GADGET from a property, or give it in a QVariant. You can't extend the object like that, but we can access their properties. However, the final attribute does not help much.

would there be some optimization opportunities in QtCore about this or not at all ?

I can't think of any optimization that this attribute would allow.