Hi, have you considered how you can keep compatibility, by making this change either opt-in or opt-out? Since it seems the refactoring is already done, it feels like you are making a bet that only has a negative outcome for those porting/trying to keep up. 😊 Good for maintenance, bad for users?
OK, I'm convinced. My experiments have unearthed lots of "interesting" behavior, but the basic example of having two engines with different import paths both load some document works. That is, the resulting QML types are indeed different. So I've dropped https://codereview.qt-project.org/c/qt/qtdeclarative/+/527526 - the change that makes compilation units visible across engines. The refactoring for splitting the compilation units in a way that eliminates engine pointers from the global type registry is still a good idea, but it can be done without any functional changes.
The minimal fix for QTBUG-120189 is to double check the engine-specific type loader for any property type added to the property caches. This isn't pretty but it does the trick. See https://codereview.qt-project.org/c/qt/qtdeclarative/+/529215
In the long run, we have to untangle this somehow. You can't have different types for the same document in different engines and _also_ store all of this in a global type registry that assumes you have a unique type for each URL. Currently this assumption is enforced in some places but deliberately avoided in others.
When we get qmltc and qmlcachegen into a shape where the code generated by qmltc can directly call the functions and expressions compiled by qmlcachegen we won't need much of an engine anymore if you exclusively run pre-compiled code. When running the QML code through the interpreter or JIT we might then duplicate the type registry for each engine and isolate the type registries against each other. Those could then be safely used with custom import paths, URL interceptors etc. That's still quite a way to go, though.
best, Ulf -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
