Hi Ulf,
Thanks for the advice. I think I got it working.
Patch submitted on Gerrit:
https://codereview.qt-project.org/c/qt/qtdeclarative/+/345339
It includes documentation and a test, and it works with named imports (i.e.
import { version } from "info")
Mostly it was just storing the QJSValues as PersistentValues, then
converting them to StaticValues when needed.
There were some other things, like telling the engine to skip calling
loadModule in the ExecutionUnit if it's already been registered in
nativeModules.
It works for any QJSValue, but one thing that might make this feature more
useful in the future is exposing functions or methods as a QJSValue.
One way might just be to have a std::function constructor (for a lambda)
Another might be to have QJSValue act as an intermediary between an
imported function in JavaScript and a slot in a QObject. That might require
some internal changes though.
But that's a whole different discussion. For now, I hope this works.
Thanks for your advice,
Alex
On Thu, Apr 22, 2021 at 1:55 AM Ulf Hermann wrote:
> Hi Alex,
>
> the simplest way I can see here would not be a compilation unit. The
> compilation unit is only needed if you want to run JavaScript. The place
> where the imports of a script are saved is
> QV4::CompiledData::CompilationUnitBase::imports of the _importing_ unit.
> That's an array QV4::StaticValue*. Imports are always resolved
> statically when loading the script that does the import.
>
> You need a way to tell the engine "Hey, here is my implementation of
> foobar, use that when importing foobar in JavaScript". Then you can just
> provide a QV4::Value (that has been protected against garbage collection
> in some way) as that will fit the bill for the imports array.
>
> You might store those values as a hash of QUrl to QV4::PersistentValue
> in QV4::ExecutionEngine. Then you can query them in addition to the
> compilation units whenever something is imported. In a second step, the
> original modules hash may be changed to store some abstraction over both
> variations.
>
> This of course does involve some changes in the QML engine itself.
> However, better integration of C++ into JavaScript (as opposed to QML)
> has been on my list for a long time. This would be a welcome addition.
> Don't hesitate to ask me if you have further questions. You can also
> find me on freenode IRC in the #qt-v4vm channel.
>
> best regards,
> 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
