Closed aardappel closed 5 years ago
Not specify that mapping i32 to object has to go through tables, or how those tables are to be stored in a wasm module. If we have a generic way for embeddings to work with tables, this can still work, but I can imagine a particular embedding (even JS) could instead manage these itself in an array of objects in its managed space, without the need to use wasm tables for this.
What do you mean by this? Tables are a wasm-side feature, not an embedding-side feature, and there's plans to introduce opcodes that allow wasm to copy elements from one table index to another. What do you propose these i32 values mean if not indexes into tables, and how do you propose wasm code manages them?
@magcius Yes, exactly, I advocating to keep wasm-side and embedding-side (JS) cleanly separated, which I don't feel this is doing.
Enabling wasm to copy a host object can be done in all sorts of ways and does not need to be coupled with the table mechanism necessarily. Certainly adding opcodes to wasm that are specific to bindings of a particular language/embedding does not sound desirable to me.
I believe the current idea is that this host binding spec is JS-specific and becomes part of the JS API spec.
Identifying and factoring out non-JS parts seems like over-engineering at this point. For one, we don't have any experience with other embeddings, so it's hard to predict what parts (if any) of the binding stuff is universal. We can always refactor specs once other bindings appear and enough common ground materialises, but for now I would just stick to keeping it simple.
Closing as fixed: the current proposal, which has evolved a lot since this issue was opened, is no longer bound to JS specific semantics
Reading the overview, I feel this proposal addresses several needs:
i32
's in wasm import/exports actually mean for a given host embedding. This is definitely very much needed.i32
(in this case, through extra tables).And one concern that is I am missing being addressed:
It seems to me that these 4 concerns would be best addressed orthogonally. So far, the wasm spec, while in its primary implementation is intended to be used with JS, has been specified as a very general low-level machine with no dependence on any JS semantics. This proposal could end up adding a lot of JS specifics, which may not serve future uses well, even if optional.
Specifically, I'd suggest:
i32
to object has to go through tables, or how those tables are to be stored in a wasm module. If we have a generic way for embeddings to work with tables, this can still work, but I can imagine a particular embedding (even JS) could instead manage these itself in an array of objects in its managed space, without the need to use wasm tables for this. In the end, ani32
in linear memory will be an unreliable reference, regardless of wether tables are used or not.