Details
-
Task
-
Resolution: Unresolved
-
P2: Important
-
None
-
None
Description
When upgrading to newer versions of Qt people often want their code to work with both the old and the new version. At the same time they want to use new features added in the new version. In QML such features may be new modules, types, or properties. Currently it is very complicated to do such a thing. For example, a binding on a new property would have to be assigned using Qt.binding() in procedural code after checking the availability of the property.
A better solution may be a language construct that optionally imports a module, instantiates an object, or assigns a binding if the respective conditions are met. We could append a question mark to the relevant names to signify the optional nature:
import QtQuick import FooBar? Item { FooBarElement? { fooBarProperty?: 5 property fooBarValue a? } }
There was an idea to have some kind of preprocessor instead. That idea had problems:
- The conditions would have to be phrased based on versions. Versions should go away, though
- Tooling would have to decide whether to include or exclude the optional code blocks. This is not easy since it would have to evaluate the expressions.
With the proposal above, we get rather simple expressions. It's only "is X available?". It makes verification of the optional identifiers rather hard since the tooling won't know if an identifer is mistyped or just not available in a specific version. To help with that, we might add an additional annotation:
@Available { module: "FooBar", version: "2.5" } Foobar? {}
This way the tooling (that evaluates annotations) can verify this in case you actually have FooBar 2.5.
Attachments
Issue Links
- resulted from
-
QTBUG-16854 Conditional Imports
-
- Closed
-