On Thu, Sep 24, 2015 at 9:04 AM, Attila Csipa <[email protected]> wrote: > On 9/21/2015 10:51 PM, Alan Alpert wrote: >> >> I found part of the previous discussion, see my essay from 2012 which >> explains the versioning system:http://alan.imagin-itis.net/?p=322 > > > Not a new discussion, indeed :) >> >> Now in the next minor version of Qt, say we add a QQmlFlange class to >> QtQml. A application built against the current version of Qt, but >> linking to system libraries, will continue to work fine. The name >> resolution happened at the linker stage and so a new symbol in the >> shared library doesn't affect the behavior of the compiled binary. >> "flange" will still be an instance of the local QQmlFlange and you >> won't hit the name conflict until you try to compile against the new >> Qt version. >> >> Contrast to the example I gave Robin, where the QML name resolution >> happens at runtime, and you can see why #include<QtQml> is so much >> safer than import QtQml. > > > This is a red herring - given MOC and QObject properties, there is no > guarantee (other a statistical "we add less properites to C++ classes than > to QML, so there is less change of namespace overlap"). At best, this would > indicate differences of defaults, but not versioning enforcement. > > Here's an example: > > QScreen* scr = qApp->screens().at(0); > > qDebug() << scr->property("devicePixelRatio"); > qDebug() << scr->setProperty("devicePixelRatio", 100); > qDebug() << scr->property("devicePixelRatio"); > > On Qt5.3, this gives > > // QVariant(Invalid) > // false > // QVariant(int, 100) > > On Qt5.5, this gives > > // QVariant(double, 1) > // false > // QVariant(double, 1) > > It's clear that there will be no compile time difference, but given the > different *runtime* outcomes, the app behavior can be altered completely > transparently to the developer. That's why it feels that the QML versioning > *enforcement* is pretty arbitrary, as both C++ and QML can be written in > both static and dynamic manners. Even if we say that "well Qt on the C++ > side doesn't use properties that often", it doesn't take into account 3rd > party code, or how much it (doesn't) rely on either QML or C++ properties in > it's own classes.
The point of versioning isn't to prevent different runtime outcomes, that's not possible as you have showed. But there's an implicit compile step when you run a QML file at program startup, and the versioning system prevents that from failing. Getting different values is a problem, yes. But those lines still ran, and you could theoretically use runtime error handling code. If there suddenly appears a type conflict in a QML file, the compilation stage *fails* and the QML code never reaches its own "runtime" to experience the different outcomes (we are in the runtime of the C++ application, but bailed on compilation of the QML files). If QML was untyped you could probably let it slide, as different values at runtime is a much harder problem to solve. But when you can change the type of a variable in a binding and then the file will simply fail to compile, that's guaranteed application breaking. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
