Open lygstate opened 3 years ago
So one of the things with that proposal was that it would enable WASM <-> JS interaction for the wasm gc, in fact you can even see that in the explainer that this is the primary idea for typed objects:
To do this, we propose to revive, refurbish and repurpose the old Typed Objects proposal. The new Typed Objects proposal is designed with WebAssembly in mind and is motivated as follows:
Although it does beg the question, could this proposal satisfy that use case? One such way it could is just to guard/coerce like webassembly JS wrappers already tend to, however this is an obvious performance cost.
For wasm-defined struct types it would already be viable to expose a wrapper that intercepts getters/setters for the indexed fields.
However one of the things with that proposal is it wants to allow JS to expose custom host types.
For example in that proposal you could define:
const Point = new StructType([{name: "x", type: int32}, {name: "y", type: int32}]);
const p = new Point(0, 1);
and actually instantiate modules with such types:
const instance = await WebAssembly.instantiate(wasmModule, {
host: { Point },
});
which the internal wasm module could then actually use to create actual instances of such objects:
(type $Point (import "" "Point") (eq (struct (field $x i32) (field $y i32))))
;; some method returning a Point
(func (export "makeOrigin")
(struct.new $Point (i32.const 0) (i32.const 0))
)
in which case such values would really be Point
objects:
instance.exports.makeOrigin() instanceof Point; // true
It's not clear to me that such patterns cleanly fit into struct class
as proposed here, they feel like fairly different features.
Perhaps a decorator approach with struct class
could be viable? I'm not sure:
@WebAssembly.StructType
struct class Point {
// Decorate with layout and type information so that it can satisfy
// (struct (field $x i32) (field $y i32))
// with the correct fields in the right layout positions
@WebAssembly.StructField(0, "i32")
x;
@WebAssembly.StructField(1, "i32")
y;
}
Well, I asked for this because FFI also need this, yes, we have @WebAssembly.StructType, but we also can have
@FFI.StructType struct class Point { // Decorate with layout and type information so that it can satisfy // (struct (field $x i32) (field $y i32)) // with the correct fields in the right layout positions @FFI.StructField(0, "i32") x;
@FFI.StructField(1, "i32")
y;
}
Indeed, WebAssembly
is also a subtype of ffi.
FFI are binding to specifc architecture and ABI.
It does not explicitly supersede it, but that proposal is not being worked on at the moment.