-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Trait-based Web API bidnings #3934
Comments
I don't quite understand why the initial For the (persumably main) goal of using a |
The idea is that if we implement all the traits for the same type, we can sort of "view" any It is, however, very inconvenient, as it effectively erases the types - you can still restrict the types as But we effectively want to represent a somewhat TypeScript-y thing, where we have any arbitrary types, but we view them as implementing certain interfaces or traits. We don't necessarily want to have a notion of the concrete type - but we want some fixes view of the value type, rather than having a generic So, that's where |
I couldn't really find what exactly the goal or the motivation behind this is in the OP, would you mind going into that and how this isn't solved by the existing mechanics? |
So I tried reading it again with fresh eyes and am unfortunately not closer to understanding what exactly this is trying to achieve. Happy to re-open upon further clarification! |
Let's take a
WritableStream
for example.If it was a trait, could just implement it for a
JsValue
, like so:impl WritableStream for JsValue { ... }
(with some codegen of course).Then, if needed, we could very elegantly extend
WritableStream
withWebTransportSendStream
with an explicittrait WebTransportSendStream: WritableStream { ... }
- and also implement theWebTransportSendStream
forJsValue
.With the given WebIDL:
WebIDL
The traits would look somewhat like this:
Traits
and impls like this:
Impls
A couple things to note:
the idea of having a:JsAny
type, that would work somewhat like adyn std::any::Any
and enable typechecking of the underlying type of anyJsValue
UPD: no! actually, what we just need is this:
trait JsAny { fn as_js_value(self: Self) -> JsValue }
;JsValue
already has all the impls, so this effectively allows us to castimpl WebTransportSendStream
toJsValue
and from there to anything:This might look scary - but you would just always use generics or trait object if an issue is encountered here.
Also, we should consider having something like this:
JsValue<dyn WebTransportSendStream>
- theJsValue
is already effectively a pointer to a value, but this way it can also carry on the information about the associated API.Then we'd implement the traits for
impl WebTransportSendStream for JsValue<dyn WebTransportSendStream> { ... }
to provide the type restrictions...the shims being standalone functions instead of being implementation details of a given type.
Originally posted by @MOZGIII in #3933 (comment)
The text was updated successfully, but these errors were encountered: