Maybe I could be clearer on the part of the mechanism that I find complex. Currently the module support I’ve build for JS mirrors how NodeJS does it, which is that every library that is referenced by a script causes the runtime to go out and find the library, load and cache it, then return the symbols to script (this may happen recursively). These libraries are cached in ‘module’ instances which link to each other as dependencies.
As I mentioned, I have considered switching the GraalJS runtime to this approach for script extensions, so that a script can explicitly import/require the symbols from a specific grouping. When I think about how I would do this, it would make sense to put the symbols/objects into a ‘module’ instance and return it to the script (e.g. same as other lib references). The challenge arises with the current mechanism - which is that the script calls out to scriptExtension, which then asks the ScriptEngineFactory to import the symbols. It does not return the symbols. The best way that I can see to achieve this right now is:
- store the scriptExtension objects in the ScriptEngineFactory, keyed by containing ScriptEngine
- when I get a request to require a special/runtime lib (I prefixed above with @runtime, but whatever), then I would need to:
- create a new module instance with the name of the runtime module being looked up, and store in the ScriptEngineFactory, per ScriptEngine (assuming no transitive deps, and no multithreading)
- lookup the associated scriptExtension that I’ve stored for the requesting ScriptEngine (lookup in the Factory)
- explicitly call the importPreset method on the specific scriptExtension
- when scopeImports is then called, capture the symbols provided and copy them into the module (not the engine)
- return the module to the runtime
So it’s possible, but it seems much more complex than it should be - for example if importPreset returned (or also returned) the symbols then everything would be straightforward.
As for Jython, I’m a bit confused. I thought that it was pretty much the same as JS, and that you’d want to support the import/module system. For example, this is how I think it should work:
import runtime.rule_support //first I import a library
rulesupport.Bar.baz() //then I reference things from the library
But what I currently see is:
scriptExtension.importPreset("RuleSupport") // would be nice to use a standard import...
Bar.baz() //where did Bar come from?
So I think that the systems are the same, and that I’m suggesting to make the framework code able to support the native module system for the guest language. I cannot comment on whether it’s possible to achieve this with Jython, that would depend on the ability to intercept the
import call from the guest runtime (which is precisely how I acheive it in JS).