[Development] QML import versions

[Alan Alpert]

On Thu, Sep 24, 2015 at 9:04 AM, Attila Csipa <qt at csipa.in.rs> 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