Re: [whatwg/webidl] Allow static operations to have the same name as regular operations (Issue #1097)

My experience working on web-sys, WebIDL bindings for the web for Rust-compiled-to-wasm, is that naming is generally not that big of a concern. There's already a pretty large difference between WebIDL and what Rust can do. For example Rust doesn't have optional arguments. This means that something like `new DomPoint()`, to pick a random example from the docs, has [lots of constructors](https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.DomPoint.html#method.new) to expose all the various variants to Rust.

Another example is that WebIDL doesn't have a concept of ownership or mutability. This means that Rust ends up needing an [allow-list for methods that don't actually mutate their arguments](https://github.com/rustwasm/wasm-bindgen/blob/bfcf18b0ce5459246838626ef4169e994758ec31/crates/webidl/src/constants.rs#L44-L94) so we can bind them in Rust as something like `&[u8]` instead of `&mut [u8]` (as we need to otherwise pessimistically assume that JS will modify its arguments). Now that being said I haven't kept up with WebIDL in some time now so this may have changed in the intervening years!

Overall it feels like 95% of the bindings translation from WebIDL to Rust is generally handling semantics in WebIDL that are bridging JS and Rust semantics. Naming is a pretty small portion of that so while this is something that we'd have to account for it's not really any worse or better than things like [`ChannelMergerNode::remove_event_listener_with_event_listener_and_event_listener_options`](https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.ChannelMergerNode.html#method.remove_event_listener_with_event_listener_and_event_listener_options), and even that's pretty tame compared to some of the other generated methods.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1097#issuecomment-1032733229
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1097/1032733229@github.com>

Received on Tuesday, 8 February 2022 15:28:21 UTC