Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.12.3
-
None
Description
- QML Scoping rules are difficult to understand. Names are implicitly looked up in certain parent scopes (but not all) if not found locally. The rules governing this are rather confusing. It's easy to accidentally use a property of the wrong object.
- There is no C++ API for bindings. As objects defined in QML are accessible from C++, this results in some interesting interaction. There is no way to find out which bindings are affected when working with their properties in C++ and you cannot establish new bindings from C++.
- Binding updates are done immediately, not batched. This is wasteful as bindings are often evaluated multiple times in a row, with the intermediate results being discarded. See QTBUG-71577 for a more detailed description.
- QML versioning is inconsistent with C++ and intuition. In C++, versioning is not part of the language. In QML it is, but each file does its own versioning on its imports. Therefore, for an object from a recursively imported component, the properties you can access, depend on the import statement in the file that created it. You can import the same component again with a higher version in the file where you want to use the properties, but that won't have an effect. This is very confusing. Defining the versions of the components to be used centrally and outside the core language would be beneficial.
- Maintaining compatibility in C++ is much easier than in QML. Right now, due to the scoping rules, newly added properties need to be hidden if a component is imported with a lower version. Otherwise a user relying on implicit lookup in parent scopes might accidentally find the new properties rather than the ones they are looking for. In order to hide a property in earlier versions you need to assign it a new metaobject revision, and register the new version of the component with that revision, in addition to the old versions.
- C++ based context properties traverse all scopes but aren't declared anywhere in the language itself. Therefore, they are "magic" names which you cannot know about when just looking at the QML code. Also, the lookup of those names produces some complicated and expensive code paths in QML itself which are also executed if no context properties are registered. It is also very hard for any tools to know which context properties are available without executing the code itself. Context properties can be added and removed at runtime from any C++ code, after all.
- You cannot bind to JavaScript properties. You can add JavaScript object as properties to QML objects, but the properties of the JavaScript objects are not QML properties, but rather JavaScript values. Therefore you cannot establish any bindings on them. Referencing those values in a binding "works" in that the values are used when evaluating the binding, but changing the values does not trigger re-evaluation.
- QML does not have a notion of private properties. Any properties declared in an object are visible to any user of the object. This makes it hard to encapsulate components.
- Allow to specify a predefined set of types to be assigned to a property (e.g. std:variant).
This allows to check types already at compile time and prevents excessive error/type handling when the property is set
MyItem {
prop: CustomType1 {}
}
MyItem {
prop: CustomTyp2 {}
}
Attachments
Issue Links
- relates to
-
QTBUG-71577 QML needs a way to atomically update multiple bindings at the same time
-
- Open
-
- resulted in
-
QTBUG-73675
Streamline QML for better toolability and performance
-
- Open
-