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

Add ability to attach protocols to generated models #573

Closed
armintelker opened this issue May 17, 2024 · 10 comments
Closed

Add ability to attach protocols to generated models #573

armintelker opened this issue May 17, 2024 · 10 comments
Labels
kind/feature New feature. status/triage Collecting information required to triage the issue.

Comments

@armintelker
Copy link

Motivation

We need all of our models generated by swift-openapi-generator to comply with protocols like Equatableor Identifiable to work with our overlaying architecture. Manually extending each generated model to conform to these protocols is insufficient and cumbersome, especially as the number of models increases.

Proposed solution

Add a feature to the swift-openapi-generator that allows specifying which protocols the generated models should conform to. This could be implemented as a configuration option in the generator, enabling automated protocol conformance during the model generation process.

Alternatives considered

The current workaround is manually extending each generated model, like so:

extension ModelA: Equatable {}
extension ModelB: Equatable {}
extension ModelC: Equatable {}
extension ModelD: Equatable, Identifyable {
    var id: Int 
    //...
}

However, this approach is not scalable and becomes unwieldy as the number of models grows.

Additional information

If there is already an existing feature to achieve this, i apologize for the oversight and kindly request guidance to the relevant documentation. I could not find any reference to such a feature in the current documentation.

References:

Identifiable Documentation
Equatable Documentation
Thank you for considering this request.

@armintelker armintelker added kind/feature New feature. status/triage Collecting information required to triage the issue. labels May 17, 2024
@czechboy0
Copy link
Collaborator

Hi @armintelker,

all generated types already conform to Equatable, as we generate the Hashable conformance (which includes Equatable).

Identifiable, on the other hand, is tricky, as it's not clear what the id property should return for arbitrary schemas. What would be your expectation?

@armintelker
Copy link
Author

Hey, thanks for the quick response.
I have overseen that the DTO is already conforming to Hashable. This makes, of course, everything a lot easier. So my request gets kind of needless.
Indeed the Identifiable protocol suggestion would be more like a "nice to have".
I could imagine that the generator could add the Identifiable to the model as soon it sees a property id exists that also conforms to the constraint of the protocol.

@czechboy0
Copy link
Collaborator

I could imagine that the generator could add the Identifiable to the model as soon it sees a property id exists that also conforms to the constraint of the protocol.

In theory yes, but my first instinct is that this would be considered out of scope of an OpenAPI generator. I think a separate build plugin that processes your Swift code and adds Identifiable to any struct that has an id property would be more appropriate, and more maintainable. This is a feature that would be useful outside of the OpenAPI context.

@simonjbeaumont
Copy link
Collaborator

This is similar to #383, where could conceivably attach arbitrary conformances or macros that are stated in the config file and it be up to the adopter to ensure these are available in their project.

It wouldn't be too different from the ability we have know to express additionalImports.

@czechboy0
Copy link
Collaborator

That's true, @simonjbeaumont, and the macro itself would contain the logic for how to e.g. implement Identifiable, instead of the generator having to know how to do it. I like that.

@shadone
Copy link

shadone commented Jun 16, 2024

+1 to this. In my use case it would also be useful to have ability to add Identifiable conformance to some types. There is literally no other way to do this - I have a library that uses swift-openapi-generator to generate the type and expose them publicly.

It would be nice if Swift allowed to add public conformance to a protocol in an extension:

public extension Components.Schemas.SortType: Identifiable { // compiler error: 'public' modifier cannot be used with extensions that declare protocol conformances
    public var id: String { rawValue }
}

Unfortunately this is not possible in Swift, so the only solution I can see is to solve it in the openapi generator.

@czechboy0
Copy link
Collaborator

czechboy0 commented Jun 16, 2024

Hi @shadone,

does this work?

extension Components.Schemas.SortType: Identifiable {
    public var id: String { rawValue }
}

(without the public modifier on the extension, only on the id property).

@shadone
Copy link

shadone commented Jun 16, 2024

<deleted previous content> I completely misunderstood what czechboy0 was saying

That work indeed, thanks @czechboy0 ! To be honest I had no idea this is possible, despite years of writing Swift code. And to be honest I do not understand why this works (does the SortType publicly conform to the protocol here or just the "shape" of the protocol)

But it works great, thanks!

@czechboy0
Copy link
Collaborator

does the SortType publicly conform to the protocol here or just the "shape" of the protocol

I believe the visibility of the conformance is always derived from the visibility of the extended type and the protocol, i.e. there is no way to privately conform a public type to a public protocol.

But to get more details, starting a thread on the Swift Forums might be a good next step, if you're interested in the lower level compiler details.

@czechboy0
Copy link
Collaborator

I believe we arrived at a reasonable workaround, so closing. Please reopen if there are new use cases which cannot be addressed with a hand-written extension, and would require changes to the generator.

@czechboy0 czechboy0 closed this as not planned Won't fix, can't repro, duplicate, stale Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature. status/triage Collecting information required to triage the issue.
Projects
None yet
Development

No branches or pull requests

4 participants