swiftwasm / WebAPIKit

Access the DOM and other Web APIs from Swift! (Very much a WIP)
MIT License
61 stars 8 forks source link

Represent at least some union types as protocols #43

Open MaxDesiatov opened 2 years ago

MaxDesiatov commented 2 years ago

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.

j-f1 commented 1 year 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).