Open dcodeIO opened 5 years ago
I don't know much about the second option - how would that work? Something like the exports would be named by strings, instead of JS vars?
That sounds good in general to me, I didn't know that it was possible to use string names for all the imports and exports that we need here.
To me it seems that ES module exports, which must be valid JS identifiers, and Wasm module exports, which allow additional characters, is generally incompatible, instead requiring exporting some sort of object that one can set arbitrary properties on. That is, if I'm not missing something.
I also wonder how this is supposed to interop with JS in the first place, since if the module has a hello#world
export, one can't do import { hello#world } from "./my.wasm"
anyway?
I'm not sure..
@alexcrichton I think you made the change to ES6 module output here, perhaps you had a plan for this stuff?
I didn't personally consider this use case when originally porting wasm2js, but I'd recommend following whatever the ES integration spec for wasm says in this regard. It might be more reasonable for wasm2js to generate an error rather than apply its own mangling scheme, but otherwise I'm not sure how wasm2js would handle this.
With Wasm2js generating valid ES modules, some information about export names is lost making Wasm modules and their Wasm2js counterpart non-interchangeable.
For example, if the Wasm module exports a function named
hello#world
, this will be exported as-is in Wasm but ashello_world
in Wasm2js output.Now one could argue that the mangling is necessary to make ES modules in the first place, and another person could argue that compatibility of the resulting module instance is more important. I'd personally favor the latter, since AssemblyScript uses export names (which do allow such symbols by the spec) to transport information about what is an instance method as part of the export's name (like
MyClass#myInstanceMethod
vsMyClass.myStaticMethod
).Any thoughts?