Support [NoInterfaceObject] in web-sys
#1449
Conversation
I'm not very familiar with |
|
According to the WebIDL spec it looks like it's just duck typing for these interfaces (and intentional that it is). It's also noted though that this is a legacy feature which shouldn't be used by anything new, so it's just compat with older APIs for now. |
I see. So that's why I wonder if Another alternative is maybe panicking in |
Since it's only run on
I think that's a reasonable compromise. I like it. |
|
FWIW I think we in general just need to expose the bindings found in the WebIDL as opposed to ensuring that all the conversions all make sense one way or another. It's already the case that calling I think that gracefully failing here is probably better than panicking because it's true that there's no instances of this class. If a panic happens it'd be due to an I don't think we can probe for the structure of an object to see if it's of the right type, because although it may have properties there's no guarantee they're functions with the right arguments and right return values. I think that unconditionally returning |
|
Your arguments make sense to me. Neither approach seems actually 100% correct, just implementing different tradeoffs, so I don't have a strong opinion on which one to choose. Perhaps the only good thing we could do in the future is actually separating types that have underlying named class vs those that don't, into own traits, so that these cases would be forbidden at compile-time. |
crates/webidl/src/first_pass.rs
Outdated
| @@ -45,6 +45,7 @@ pub(crate) struct FirstPassRecord<'src> { | |||
| pub(crate) struct InterfaceData<'src> { | |||
| /// Whether only partial interfaces were encountered | |||
| pub(crate) partial: bool, | |||
| pub(crate) has_no_interface: bool, | |||
There was a problem hiding this comment.
the negative is a bit funky (vs has_interface: bool) but I guess it makes sense in this case
There was a problem hiding this comment.
Nah seems reasonable to me to switch!
This commit enables `[NoInterfaceObject]` annotated interfaces in `web-sys`. The `NoInterfaceObject` attribute means that there's not actually a JS class for the object, but all of its properties and such can still be accessed structually and invoked. This should help provide more bindings for some more common types on the web! Note that this builds on recent features to ensure that `dyn_into` and friends always fail for `NoInterfaceObject` objects because they don't actually have a class. Closes rustwasm#893 Closes rustwasm#1257 Closes rustwasm#1315
alexcrichton
force-pushed
the
no-interface-objects
branch
from
f6be58d to
01a5223
Compare
51: Add WebGL Extensions r=grovesNL a=TannerRogalsky This enables and tracks all supported WebGL extensions. It also uses those extensions to add vertex array objects and instanced drawing to WebGL1 when supported. Some areas of potential interest: - stdweb's VAO extension implementation returns a different type than the non-extension implementation. I've resolved this by tracking the extension resource separately but with the same key type. - WebGL extensions are all `[NoInterfaceObject]`s and aren't represented as JS classes and therefore can't be cast into Rust classes in the normal way (using `JsCast::dyn_into`). Instead `unchecked_into` is used along with the web_sys-provided Rust classes to duck-type these extensions. As I understand it, [this is the expected way](rustwasm/wasm-bindgen#1449). - I've employed a macro to cut down on code duplication around the web_sys extension creation because their WebGL1 and WebGL2 context share an API but not a useful trait. I'm of course open to any suggestions on how to improve this. Co-authored-by: Tanner Rogalsky <[email protected]>
This commit enables
[NoInterfaceObject]annotated interfaces inweb-sys. TheNoInterfaceObjectattribute means that there's notactually a JS class for the object, but all of its properties and such
can still be accessed structually and invoked. This should help provide
more bindings for some more common types on the web!
Note that this builds on recent features to ensure that
dyn_intoandfriends always fail for
NoInterfaceObjectobjects because they don'tactually have a class.
Closes #893
Closes #1257
Closes #1315