tc39 / proposal-structs

JavaScript Structs: Fixed Layout Objects
http://tc39.es/proposal-structs/
622 stars 11 forks source link

Does this are a replacement of https://github.com/tschneidereit/proposal-typed-objects? #4

Open lygstate opened 3 years ago

syg commented 3 years ago

It does not explicitly supersede it, but that proposal is not being worked on at the moment.

Jamesernator commented 2 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;
}
lygstate commented 2 years ago

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.