ifsheldon opened issue #9774:
I don't know whether this is a bug or expected. I personally would consider it as a minor bug, but I leave it as a feature request.
Feature
I'd like
bindgen!
generates a sensible name for the bindings of interfaces in a WIT file.I have this WIT file. It exports an interface called
add
that contains only one functionadd
.package component: interfaced-adder; // See https://github.com/bytecodealliance/cargo-component/issues/360 for why this is needed // Also according to https://component-model.bytecodealliance.org/creating-and-consuming/composing.html, "Composition happens at the level of interfaces" interface add { add: func(a: s32, b: s32) -> s32; } world adder { export add; }
In my Rust host, I need to run an
adder
component, so I write the host code likebindgen!({ path: "../wit-files/interfaced-adder.wit", world: "adder", }); pub fn run_adder_sync(engine: &Engine) { let (component, linker, mut store) = get_component_linker_store( engine, "./target/wasm32-wasip2/release/guest_interfaced_adder_rs.wasm", "../target/wasm32-wasip2/release/guest_interfaced_adder_rs.wasm", ); let bindings = Adder::instantiate(&mut store, &component, &linker).unwrap(); let a = 1; let b = 2; // TODO: interface0 seems weird, file an issue let result = bindings.interface0.call_add(&mut store, a, b).unwrap(); assert_eq!(result, 3); }
Instead of a meaningful name like
"add"
,bindgen!
somehow generate the binding for interfaceadd
with the name"interface0"
. This seems weird to me. And I don't see why it can't be named as the same as the interface name.bindings.add.call_add
seems more natural to me.Benefit
The current naming is bad for readability and understanding, as no one can see from
interface0
that it has any relation to the interfaceadd
.interface0
means just the first interface.Changing the naming can improve readability, understanding and code writing.
Implementation
No, I am not very familiar with bindgen internals.
alexcrichton commented on issue #9774:
I believe
interface0
here is an internal name in the struct, and the intended interface should bebindings.component_interfaced_adder_add().call_add()
where the firstcomponent_interfaced_adder_add()
gives you a structure representing theinterface add
. Does that work here?In this example it would be this method
ifsheldon commented on issue #9774:
That works. Thanks! But I still think we should give a better name to this field, even if it's internal.
Besides, the name scheme
bindings.<package name>_<world name>_<interface name>()
seems a bit too verbose to me, since in the bindgen! we have already specified the WIT file, so we can assume the bindgen users have already known the package and world of their choice. I think simplebindings.<interface name>()
would be better.Also, this method
bindings.<package name>_<world name>_<interface name>()
has no autogenerated documentation in code, I think a simple oneliner would be great, likeBindings for <package name>/add
.
alexcrichton commented on issue #9774:
Auto-docs sounds great yeah, but we can't easily change it to just
<interface name>
because thisworld
is valid and would then have invalid bindings:world some-world { export foo; export foo: interface { ... } } interface foo { ... }
While I agree it's wordy, it's needed to disambiguate.
ifsheldon commented on issue #9774:
because this world is valid and would then have invalid bindings
What!? I don't know that. So WIT specs allow exporting two interfaces that have the same name in the same world? This seems crazy to me. I guess in this case, we would just use
foo1
andfoo2
since there's no other (sane) ways to programmatically distinguish these two, which I would consider as the fault of this WIT author.
alexcrichton commented on issue #9774:
Well, to clarify, these are two different syntactic forms of exports. One is a "full interface" which is technically named
ns:pkg/foo
where the other is a "kebab export" where the name is justfoo
. These are not distinguished asfoo1
andfoo2
but asns_pkg_foo()
andfoo()
today. I was trying to explain the origins of why the name is slightly wordy right now.
ifsheldon commented on issue #9774:
OK, seems I just need to dig into WIT specs........ but first let's get auto-docs working
Last updated: Dec 23 2024 at 12:05 UTC