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

this arg for methods in JS API #153

Closed
bvibber opened this issue Oct 17, 2020 · 5 comments
Closed

this arg for methods in JS API #153

bvibber opened this issue Oct 17, 2020 · 5 comments

Comments

@bvibber
Copy link

bvibber commented Oct 17, 2020

In light of recent discussions about JS interop over on #150 I revisited the MVP-JS.md document.

A common scenario for JS APIs is to pass objects around that have both readable and sometimes writable properties and callable methods; I believe this must be supported also on the "JS typed object" views of GC structs for the goal of code migration to be achieved.

However, while it is apparently possible to attach a prototype object with function reference properties on it when creating a struct type from JavaScript and importing it into Wasm, I don't understand how the methods are supposed to pass a this parameter with the target object unless the method functions are also written in JavaScript.

This would seem to mean that to create an interoperable struct type you must:

  • write a JavaScript module as well as a Wasm module
  • create a prototype object in JavaScript with regular JavaScript functions that forward to the module's Wasm functions while currying the this argument into the regular arguments
  • resolve the circular dependency between importing a type with functions that reference exported functions that haven't been exported yet at import time -- perhaps by modifying the prototype after instantiating the module, but before calling any code in it

I'm wondering if there might be a way to apply Wasm functions directly to a prototype without an intermediary JavaScript function or if that's considered an unavoidable limitation of this proposal.

@fgmccabe
Copy link

The Interface Types proposal will have a method (sic) for doing this.

@bvibber
Copy link
Author

bvibber commented Oct 19, 2020

Where can I see the docs for this? I don't remember seeing it in the proposal.

@bvibber
Copy link
Author

bvibber commented Oct 19, 2020

@fgmccabe are you thinking of this discussion? WebAssembly/interface-types#87 It seems incomplete and undecided so far.

@bvibber
Copy link
Author

bvibber commented Oct 19, 2020

Also just want to check if IT is a required dependency for GC to reach its goals, or if they're meant to be separate specs which can be implemented independently?

@tlively
Copy link
Member

tlively commented Nov 1, 2022

We have consensus to have "no-frills" JS interop (#279) in the MVP, so there won't be any way to install custom prototypes on GC objects. Exported accessor functions will be the only way to inspect or modify WasmGC objects from JS. PRs adding ideas for richer interop to the post-MVP doc would be very welcome, though.

@tlively tlively closed this as completed Nov 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants