Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-82766

Uncontrolled aliasing of data via grouped properties and aliases

    XMLWordPrintable

Details

    Description

      QML allows us to create bindings on grouped properties and aliases, for example like this:

      // MyText.qml
      Text {
         font.bold: true
         property alias label: text
      }
      

      Using these constructs we can create undefined behavior using multiple bindings on the same data. For example, we might instantiate the component above as follows:

      MyText {
          font: Qt.font({family: "sans"});
          label: "foo"
          text: "bar"
      }
      

      This will work, and remove the font.bold added by MyText.qml, as well as randomly choose "foo" as the text to be displayed. While this is still somewhat benign, we can easily create complex hierarchies of properties which are bound from multiple places, without a clear order of precedence. Consider:

      import QtQuick 2.12
      import QtQuick.Window 2.12
      
      Window {
          visible: true
          width: 640
          height: 480
          title: qsTr("Hello World")
      
          MyText {
              id: tt
              anchors.fill: parent
          }
      
          property alias t1: tt
          property alias t2: tt
      
          t1.font: Qt.font({family: "sans"});
          t1.label: "foo"
      
          t2.font.italic: true
          t2.text: "bar"
      }
      

      This crashes. Even if it didn't, it wouldn't be clear what it should do. Should the text be "foo" or "bar" now? Should the font be bold, italic, sans or all of that? Aliasing and grouped properties allow us to trigger these effects from different files, making it even harder to track down what is going on.

      We need to find replacements for these constructs. For object types, inline components can often be used to encapsulate a set of defaults and allow further derived components to use that without having to use grouped properties. For value types a different mechanism needs to be found.

      Furthermore, when overriding a property that contains an object type in a derived component, the base component's property is still instantiated, with the object defined there. This is because creating the object may have side effects. Therefore, simply using inline components as replacement for grouped properties on object types is currently infeasible.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              qtqmlteam Qt Qml Team User
              ulherman Ulf Hermann
              Vladimir Minenko Vladimir Minenko
              Cristian Maureira-Fredes Cristian Maureira-Fredes
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:

                Gerrit Reviews

                  There are no open Gerrit changes