The custom descriptors proposal includes a new configureAll builtin. Among other things, configureAll has the ability to wrap WebAssembly function references to make them callable with new. configureAll takes a JS object as an externref argument and writes all the constructors it creates this way as properties on that object.
This way of "returning" an arbitrary number of constructors by writing them to an object works great for hand-written JS (the object they are written to can even be globalThis, making the constructors ambiently available), but does not play well with ESM integration. With ESM integration, it would ideally be possible to export these constructors directly, which is presumably what an equivalent JS module would do.
The best method I've come up with for exporting constructors created by configureAll is to do this:
- Import helper functions for creating a fresh JS object and accessing an object's properties by name.
- In the start function, call
configureAll, passing it a fresh JS object allocated via the allocation helper.
- In the start function, use the property access helper to pull out each configured constructor and assign it to an exported mutable global.
AFAICT, there's no way to avoid the exported globals being mutable because they cannot be initialized with constant expressions.
If anyone has any better ideas, I'd love to hear them. The only other thing I've come up with is that we could have a name mangling scheme on function exports that tells ESM integration to generate the same new-callable wrapper that configureAll would have generated. This is only a partial solution, though, because it does not link up the constructor function with a configured prototype the way configureAll does.
The custom descriptors proposal includes a new
configureAllbuiltin. Among other things,configureAllhas the ability to wrap WebAssembly function references to make them callable withnew.configureAlltakes a JS object as anexternrefargument and writes all the constructors it creates this way as properties on that object.This way of "returning" an arbitrary number of constructors by writing them to an object works great for hand-written JS (the object they are written to can even be
globalThis, making the constructors ambiently available), but does not play well with ESM integration. With ESM integration, it would ideally be possible to export these constructors directly, which is presumably what an equivalent JS module would do.The best method I've come up with for exporting constructors created by
configureAllis to do this:configureAll, passing it a fresh JS object allocated via the allocation helper.AFAICT, there's no way to avoid the exported globals being mutable because they cannot be initialized with constant expressions.
If anyone has any better ideas, I'd love to hear them. The only other thing I've come up with is that we could have a name mangling scheme on function exports that tells ESM integration to generate the same
new-callable wrapper thatconfigureAllwould have generated. This is only a partial solution, though, because it does not link up the constructor function with a configured prototype the wayconfigureAlldoes.