Migrate WasmModule construction to top-level factory functions.

dart-archive / wasm

Utilities for loading and running WASM modules from Dart code

https://pub.dev/packages/wasm

BSD 3-Clause "New" or "Revised" License

312 stars 24 forks source link

Migrate WasmModule construction to top-level factory functions. #94

Closed modulovalue closed 1 year ago

modulovalue commented 1 year ago

See #92 step 2.

The following are some TODOs as a note to myself:

the circular dependency between runtime.compile and WasmModule should be broken by having the owner be a function that receives the pointer and returns an owner and a generic return type.
the async version for constructing a WasmModule is not doing anything that the sync version isn't doing and could be removed. It seems to act as a reminder for providing an async construction scheme in the future?

liamappelbe commented 1 year ago

What's the rationale for switching to top-level factory functions?

The async version is there for when we add web support. Wasmer doesn't have a built in way of compiling asynchronously, but on the web that's the main recommended way.

modulovalue commented 1 year ago

What's the rationale for switching to top-level factory functions?

By routing all ways to instantiate a wasmer based WasmModule through these two top level factory functions we'll be able to make everything else private in that file to explicitly exclude it from the public API. (we could use parts, but that would add a dependency on wasmer to wasm_api.dart).

Together with wasm_api.dart (from the other PR) we'll have a clear picture about what constitutes the public API of this package: wasm_api.dart (all sealed interfaces) and two functions for creating new wasm modules. This will give us more freedom to work on the internals without accidentally breaking users of this package.

liamappelbe commented 1 year ago

Sounds reasonable. How would we provide a different implementation of these functions for the web? Just delegate to impl functions defined in conditionally imported scripts?

modulovalue commented 1 year ago

Conditional imports would be one way.

However, there are some subtleties that make conditional imports suboptimal in my opinion. One of which is that they aren't really supported all that well by the dart analyzer. (But they are the most user friendly way in the sense that users won't have to care about any implementation details.)

modulovalue commented 1 year ago

changelog updated (and version bumped)

modulovalue commented 1 year ago

I've rebased on main and squashed the commits. @liamappelbe please take a look. I don't have write permissions to merge or is there something else that you'd like me to do?