[Development] Convenience Imports in QML

[Alan Alpert]

On Wed, Dec 12, 2012 at 7:41 AM, Attila Csipa <qt at csipa.in.rs> wrote:
> On 12/12/12 12:22, Sorvig Morten wrote:
>> On Dec 11, 2012, at 4:25 AM, Alan Alpert <416365416c at gmail.com> wrote:
>>> import Qt 5.0
>>>
>>> Which imports all QML modules in the Qt Essentials released with 5.0.0
>
> If the idea is to import the essentials, then call it that: "import
> QtEssentials (from Qt) 5.0" - it would look weird enough to explain why
> you can't combine this "Qt5" module with, say, cascades or something
> similar.
>
>>> (except QtQuick 1). It would be the equivalent of
>>>
>>> import QtQml 2.0
>>> import QtQuick 2.0
>>> import QtQuick.Window 2.0
>>> import QtQuick.Particles 2.0
>>> import QtAudioEngine 1.0
>>> import QtMultimedia 5.0
>>> import QtWebkit 3.0
>> How about allowing imports without the version number?
>
> Oh, how many times we have discussed this :)
>
> I'll agree that the "import QtQml from Qt 5.0" is cleaner. But my
> "ceterum censeo" on the QML versioning and why (the way it's implemented
> - though not necessarily the way it was envisioned and described in
> Alan's post) is fundamentally broken: QML import statements try to link
> code to *VERSIONS* and not *API*s (hold your thoughts there for a second
> and let that sink in - the difference is subtle, but important). The
> insult-to-injury there is that the versions mentioned there are actually
> ID strings and contain no semantics or relations. What I would like to
> see a lot more is the logic applied for the good old C++ side: major
> version means compatibility, minor version means features, not ad-hoc
> numbering schemes. So if I do an Import QtQml 2 (or QtQml 2.*, or 2.0+)
> it means I'm good with anything that provides 2.0 or a compatible API.
> If you have QtQml 3.0, it means you had an API break and then it's
> perfectly fine to say 'bork, import failed'.

That is exactly what it is supposed to be, and this is why we can't
(or at least shouldn't) just follow Qt versioning.

Major version means high-level incompatibilty, so if you import QtQml
2.0 now don't expect it to just work with QtQml 3.0. Minor version
means features, which actually means some low-level incompatibilty
because it's a different language to C++. So QtQml 2.1 is mostly the
same as QtQml 2.0, just some new features, but you still should check
that the new features don't lead to resolution conflicts before you
redeploy. So QML modules might have to jump the major/minor version
separately to Qt, and vice-versa (no new QML symbols? Don't update
your module version number just because it's Qt 5.1!).

Imagine that Qt used C instead of C++, and all functions were suddenly
just global functions in a namespace. They'd all start with qt_ to try
and avoid clashes, because any time Qt tried to add a feature that
means a new function that could conflict with the resolution of a
function from another library. This is very similar to QML's case, and
we probably could allow importing QtQuick 2.* if all our QML looked
like this:

QQuickItem {
    qquickitem_width: 200
    qquickitem_height: 200
}

That sort of naming is acceptable in C, and parts are done
automatically in C++ (making it way better for object oriented
programming). It's not acceptable in QML. For really fast, clean and
approachable declarative code it's better to just pick an import and
use the exact word you want.

--
Alan Alpert