Skip to content
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

Refactor Zaplib to operate on instances, rather than exported global functions #146

Open
Tracked by #177
disambiguator opened this issue Mar 21, 2022 · 0 comments
Open
Tracked by #177
Labels
enhancement New feature or request

Comments

@disambiguator
Copy link
Collaborator

The idea: A lot of the ergonomics of the framework would be easier if we had instances of zaplib instead of relying on imports.

  1. You don’t have to worry about calling initialize/initializeWorker twice, because initializing gives you the object to call callRust on and not at the top level
  2. you can move some of the awkward let variables at the global scope in the module into easy to read instance vars. less global vars in general.
  3. much easier to find in your codebase where zaplib first gets used
  4. you’ll need this anyways if you want multiple wasm binaries
  5. a bit easier to unify the api between worker and main thread (for example initializePort would be on the module not on the instance)
@disambiguator disambiguator added the enhancement New feature or request label Mar 21, 2022
@janpaul123 janpaul123 added this to the Basic stabilization milestone Mar 21, 2022
@janpaul123 janpaul123 moved this to Backlog in Current work Mar 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Backlog
Development

No branches or pull requests

2 participants