You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 move GPUCanvasContext, WebGLRenderingContext, and WebGL2RenderingContext 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.
The text was updated successfully, but these errors were encountered:
Some properties in generated code have a layer of indirection due to their use of `ReadonlyAttribute` and `ReadWriteAttribute`. There's little value in keeping these static subscripts around and introducing the indirection. Additionally, it makes makes some issues on property code hard to debug when attempting to change union types generation logic in my investigation of #43.
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 5cb70da and 6f039f2 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.The text was updated successfully, but these errors were encountered: