Open MaxDesiatov opened 2 years ago
The particular case of RenderingContext
has been handled via a manual override for the relevant types/methods, which I think makes sense due to the nature of this API. However, there are a bunch of APIs that take union-typed parameter. Currently these aren’t very ergonomic because you’d have to call e.g. myAPI(param: .string("some string"))
. The best solution would be to identify cases where the type is being applied to a value that will always be directly passed to JS (such as a method parameter) and switch the type to the protocol version. Other cases (such as properties and return values) should still stay as the enum so that they can be easily switched over by code trying to use the value.
I’ve pushed a small ergonomic update in 5cb70da9f3317bda72f11a6ec183b8a1095d1c12 and 6f039f2eceab7d03a85b10e14dced8c75877366b that allows you to call myAPI(param: .init("some string"))
or myProp = .init(someValue)
on the generated enum types, which slightly reduces the duplication of type names needed to construct an instance of that enum (especially for nested unions).
Currently, WebGL 1.0, WebGL 2.0, and WebGPU can't be split into separate modules as targets, as
enum RenderingContext
wraps all available context types and needs to have all of them in scope.If
RenderingContext
were a protocol, we could declare it in some "base" module and moveGPUCanvasContext
,WebGLRenderingContext
, andWebGL2RenderingContext
to their own respective modules adding a conformance on them to that protocol.I also thought about subclassing, but that clearly won't work due to the lack of multiple class inheritance. These types already inherit from
JSBridgedClass
, and protocols are the suggested instruments of achieving multiple inheritance in Swift.