[Development] QTCS2019 Notes from QtQml session

[Ulf Hermann]

>> While I agree with this overall, there's still one caveat which I
>> haven't seen discussed yet:
>> 
>> Imagine I have the following code:
>> 
>> Item { id: foo property color prettyColor: "#f0f"
>> 
>> Rectangle { color: foo.prettyColor } }
>> 
>> Right now "foo" refers to the Item. What if in a future update,
>> Rectangle gains a new property "foo". Unless you want to force
>> everyone to be explicit by using "this" (e.g. width: this.height)
>> everywhere, which would be annoying, I don't see how this can be
>> made future-proof without some form of versioning or some other
>> magic solution?

Indeed we need to deal with this somehow. Maybe we do need to retain 
versioning on a module level. For example, the qmldir file could specify 
what versions of which other modules it expects. Or we define that it's 
not a problem ...

> Similar things can happen in C++ with method names. C++ got the
> ‘override’ keyword to make these breakages detectable by tooling. It
> looks to me like the case id==propertyname would also be detectable
> by tooling?

We could detect this in qmllint by just continuing the search for IDs
even if we've found a property.

Mind that adding a method to a base class in C++ will shadow unrelated 
other classes and functions even if it's not virtual or overridden. Why 
did we actually decide that we can live with this effect in C++ but not 
in QML? - Maybe because in C++ it's more likely to result in a compile 
error due to mismatched signatures?

Ulf