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

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

Open
lygstate opened this issue Aug 26, 2021 · 3 comments

Comments

@lygstate
Copy link

No description provided.

@syg
Copy link
Collaborator

syg commented Aug 26, 2021

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

@Jamesernator
Copy link

Jamesernator commented May 24, 2022

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
Copy link
Author

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.

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