On 25.11.19 16:55, Robin Burchell wrote: > On Mon, Nov 25, 2019, at 3:53 PM, Ulf Hermann wrote: >> Yes, but the problems with this construct are the same as with generic >> context properties: Your QML component requires some context that it >> doesn't declare. Therefore your code is not reusable and brittle wrt >> addition of properties in other places. > Which is why I also provided a possible solution - by providing declaration > of that context. > > I'm not sure whether you just stopped reading once I started talking about > the problem, but I'd be interested to hear about whether or not something > like that approach was considered.
I think the approach that you described is semantically almost identical with required properties. Instantiation of such a component requires providing context and at the same time it's possible to keep dependencies within the boundaries of a component. > >> Mind that all those dynamic lookups will still live on in QML 2, and we >> will maintain QML 2 throughout Qt6. They just won't be valid in QML 3. > It's good to hear that QML 2 won't disappear overnight, but let's not pretend > that this would be a sustainable, good situation to be in. One day, QML 2 > will disappear. At least, given the lower version number, you would hope it > will disappear. But every piece of pain that makes porting harder will help > to ensure that it stays around longer. > > And even if there wasn't going to be pain in porting - there is going to be a > lot of residual friction in transitioning. All of the documentation, all of > the examples, all of the tribal knowledge will suddenly become irrelevant. > > And for what? Why? > > > Yes, there are problems with some features. That doesn't necessarily mean > they are unsolvable problems (perhaps they are; without having a proper > discussion about it - how do we know?) > > By the sounds of it, QML2 to QML3 will not be an easy transition. I was > already a little worried when I saw changes removing versioning, and a WIP > change deprecating context properties back in April or so, but reading your > mail makes me very concerned for the future. > > For reference, QML1 to QML2 was a _relatively_ easy port for example, despite > a different JavaScript engine, a new item set, and a completely rewritten > graphical presentation. My personal opinion is that this was very good, > because it gave you a pretty big no-brainer: spend a small moderate amount of > effort to port and validate/test, and in return, you gain much better > performance. > > The situation for QML3 seems to be much less clear cut Often we do transitions in Qt API to improve performance or perhaps interoperability. Take the discussion about the return type of size() for example, or whether QList should alias QVector or not. I sincerely hope that this transition will be different - at least today it looks already different to me and we're well into it in 5.15. The objective is to improve the maintainability of the user's code. We have added significant functionality to the linter and there is more to come. We're in the process of always applying it at build time to our own code. The work there is the foundation for the future tooling around the entire language, from a new compilation to C++ as well as better IDE integration. The current IDE integration is at its very limits (with cool hacks like scanning the C++ code for qmlRegisterType calls). Most of it boils down to the ability to make sense out of what's in the QML file without running the entire program. Dynamic scoping and context properties make it hard (sometimes impossible) to reason without running - I anticipate agreement on this :-) The application of singletons as well as required properties in our own examples has significantly improved the readability of code - that gives me the confidence that we're on the right track. Those may not be the two solutions that solve everything - however I find the evidence compelling. And by applying this step by step today, we're not making our examples and documentation irrelevant, we're transitioning and learning from it. Simon _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
