Skip to content
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

Represent at least some union types as protocols #43

Open
MaxDesiatov opened this issue May 25, 2022 · 1 comment
Open

Represent at least some union types as protocols #43

MaxDesiatov opened this issue May 25, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@MaxDesiatov
Copy link
Contributor

MaxDesiatov commented May 25, 2022

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.

@MaxDesiatov MaxDesiatov added the enhancement New feature or request label May 25, 2022
MaxDesiatov added a commit that referenced this issue May 26, 2022
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.
@j-f1
Copy link
Member

j-f1 commented Jan 29, 2023

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants