|
|
|
|
|
|
by no_circuit
588 days ago
|
|
|
For the audience that would be looking to use the WASM Component Model, and not be an infrastructure implementer of it, whether or not they meet some definition of a method, the component model does define things called resources [1] that have "methods". You'll hold a "handle" to it like you would in your own programming language with the expected drop and/or GC semantics (once implemented [2]) because code is generated to access it like any other FFI like C/C++. With that in mind, the other confusing thing one may come across is composition vs linking within your WASM runtime that supports the Component Model. When you hear "composition" think of compile-time merging of libraries such that the bundle may have less unresolved dependencies of WASM code/implemented component interfaces. Anything unresolved needs to be linked at runtime with your WASM runtime of choice, like wasmtime [3]. Pretty interesting reading/potential after reading if you ask me -- sounds like you could implement something like a custom Java classloader hierarchy [4]. But I'd agree with a statement saying it is still a long way for general usage. [1] https://github.com/WebAssembly/component-model/blob/5a34794d... [2] https://github.com/WebAssembly/gc [3] https://github.com/bytecodealliance/wasmtime/blob/ba8131c6bf... [4] https://www.digitalocean.com/community/tutorials/java-classl... |
|
|