-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extending Wasm JS API with module namespace reflection #57
Comments
I think it could be beneficial to have an explicit global module registry, similar to the custom elements registry. This notional code registry could also be used in conjunction with import maps. Such a system would have a lot of benefits , but specifically relating to wasm js imports , you could replace import “./thing.js” with ImportRegistry.get(“thing.js”). From my many experiments, i think dlang has the best user experience for interop, see https://wiki.dlang.org/Generating_WebAssembly_with_LDC . But, even this could be improved by introducing a global registry. Also , import maps are great and this would make them even greater |
Sorry I'm very late in responding to this, and thanks for writing this up. The issue of consistency with module namespace objects is interesting.
That makes sense as a possibility. Does this provide a better interface than having it exposed as
Are there any advantages, aside from consistency between the various interfaces, of exposing the exports as specifically a module namespace object? I'm also curious if this should be something tackled in the ESM integration proposal, or as a smaller adjustment to the JS API (e.g., a |
As far as I'm aware, when the original WebAssembly JS API was developed the ES module spec namespace exotic object had not been fully defined, thus
exports
was created as a plain JavaScript object, and treated as frozen for some defensibility.As a result, when the ESM integration is complete, there are two JS objects that can be used to represent a Wasm module instance - this old frozen exports object (on top of which the ESM integration is currently specified), and the module namespace exotic object,
When module linking instantiates a Wasm module, it treats it as an "instance type", which is a type it can apply to any module instance - Wasm OR JS (//cc @lukewagner if I'm getting this correct).
But the representation in JS for this instance can either be a plain JS object or a module namespace depending on how the Wasm module was instantiated (ESM integration v JS API v Wasm module linking).
This leads to some questions:
exports
object? For example via amoduleInstance.getNamespace()
or similar function?.exports
intance property to be a JS module namespace exotic object? Since the object was defensively frozen, this should mostly be backwards compatible down to the null prototype differences -.hasOwnProperty
checks etc which may cause possible ecosystem issues.It could be beneficial to start lining the specs up now along these lines to ensure there aren't any roadblocks when we get there.
The text was updated successfully, but these errors were encountered: