srujzs
commented
1 month ago Yup, this is a bug, and the proposed fix is the right solution (WebAssembly.Module). There might be a generic way to handle this by treating IDL namespaces differently.
Also, I wonder if these should / could actually be namespaced in dart in some way, I was just refactoring some code to try and use dart:js_interop and package:web, in my original implementation I used names like WebAssemblyGlobal and WebAssemblyMemory since types like Memory, Tag, Table etc are pretty generic names and caused a bit of a pain to not conflict with other imports. Not a huge problem, but it did help when reading code.
Yeah, some of the web APIs have common names as well. We can't really put these in classes so I'm not sure there's a good alternative unfortunately. We could move them to a separate folder but the end effect would be the same alas where you'd need to import them with a prefix to avoid collisions.
rutvik110
The Webassembly API should be namespaced by
WebAssemblybut several of the extension types are not properly annotated so they try to find the various type constructors in the global namespace,For example the following source for
WebAssembly.Memoryshould be annotated as@JS('WebAssembly.Memory')https://github.com/dart-lang/web/blob/4996dc2acd30ff06f7e500ec76fde8a66db82c0c/lib/src/dom/wasm_js_api.dart#L105-L109
Other likely affected interop types are:
Also, I wonder if these should / could actually be namespaced in dart in some way, I was just refactoring some code to try and use dart:js_interop and package:web, in my original implementation I used names like
WebAssemblyGlobalandWebAssemblyMemorysince types like Memory, Tag, Table etc are pretty generic names and caused a bit of a pain to not conflict with other imports. Not a huge problem, but it did help when reading code.