Hi, I don’t necessarily want to walk into the specifics of that feature of this 
change - more that I think compatibility is something that should be considered 
very valuable - to the point that prior to starting work on refactorings that 
break compatibility (in behavior in this case), there should be an option on 
the table to opt in or out of the new behavior. Otherwise, you are pushing the 
problem onto the users. The bigger the user’s codebase, the higher the chance 
that the changes will have unwanted impact. I feel qtdeclarative is 
particularly exposed to compatibility breakage-as-a-default… I wish it was the 
exception rather than the rule.

For this particular issue, I do think unittests that use QQmlEngine with 
different import paths are very common and useful. And you can’t make any 
assumptions about static networkaccessmanager or URL interceptors IMO.

The number of replies to threads in this mailing list also suggests that the 
quality of empiric data is kind of low, so I’m not sure how to conclude if, 
fex, nobody can share use cases… 😊

Andreas

Tir 9 jan 2024 kl. 10:49 skrev Ulf Hermann via Development:
> So, to clarify this some more ... If:
> 
> 1. you use _multiple_ QML engines in the same process at the same time, 
> 2. you have _different_ import paths, plugin paths, URL interceptors or 
> network access managers for those engines,
> 3. you rely on those engines to produce _different results_ for the 
> _same QML documents_ as a consequence,
> 4. this actually _works_,
> 
> please let me know more about your use case!
> 
> Using multiple engines A, B, ... sequentially where you only start 
> accessing the type registry from engine B after engine A has been 
> destructed does not count since engine A will clean up after itself.
> 
> From my point of view, looking at the source code, such a scenario is 
> rather unlikely since the global type registry should get in your way. 
> However, if it exists, I will consider it in my refactoring.
> 
> best,
> Ulf
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to