Details
-
Bug
-
Resolution: Done
-
P2: Important
-
6.2.2
-
a824a6f060 (qt/qtdeclarative/dev) a824a6f060 (qt/tqtc-qtdeclarative/dev)
Description
QML has the concept of value types which in theory should always be passed by value rather than by reference. Yet, as JavaScript is fundamentally built around references, this leads to confusing behavior. For example:
Text { Component.onCompleted: font.bold = (some * complicated * expression) }
Here, if font was a pure value type, we would retrieve a copy of it, store on the JS stack, set the "bold" property on the stack copy, and forget it. Obviously that is not what the user wants.
In order to work around this issue, value type references have been invented. A value type reference keeps a copy of the value, but also knows what property it was retrieved from. When the value is modified, it is written back. Now we get a different problem, though:
Text { Component.onCompleted: { var f = font // creates a value type reference f.bold = true // writes back otherText.font = f } }
Here, the user did not want to write the value back. Rather, they wanted to pass a slightly modified font object to a different Text element.
Furthermore, the write back mechanism only works across one level of property access. This makes it impossible to modify value types held in a container or nested value types.
A solution would be to
- add recursive value type write back.
- drop the reference and only keep a standalone value type object if the value is declared as a var, let or const in JavaScript, or when it is passed as argument to a function.
This requires changes to the byte code format. So far we don't always record whether a register represents an explicitly declared variable in JavaScript or a temporary part of some expression.
Attachments
Issue Links
- relates to
-
QTBUG-82443 Value types and Containers in QML
- Closed
-
QTBUG-126249 Writes to a Q_GADGET's writable properties are silently ignored in many cases
- Reported
-
QTBUG-109221 Inconsistencies regarding list and value type property manipulations
- Closed
-
QTBUG-28981 Date.setDate does nothing
- Closed
-
QTBUG-105241 QtLocation shouldn't use QV4 internals
- Closed