SwiftyLab / MetaCodable

Supercharge Swift's Codable implementations with macros meta-programming.
https://swiftpackageindex.com/SwiftyLab/MetaCodable/main/documentation/metacodable
MIT License
629 stars 23 forks source link

Derive access level of generate CodingKeys from @Codable model #49

Open andriyslyusar opened 11 months ago

andriyslyusar commented 11 months ago

Right now @Codable macro will generate CodingKeys with internal access level.

@Codable
@CodingKeys(.PascalCase)
public struct MessageReceiver {
    public let userId: UUID
    public let status: OData.Enum<Int>
}

extension MessageThread.Response.MessageReceiver {
    enum CodingKeys: String, CodingKey {
        case userId = "UserId"
        case status = "Status"
    }
}

It would great to generate CodingKeys with the same access level (public) as MessageReceiver. This would allow access to CodingKeys in multi package application. As of my particular use case I would like to build OData requests using CodingKeys instead of String from the domain layer of application.

Really appreciate effort in open sourcing the project, unfortunately internal macros plugin implementation is quite complicated to be able to make a quick PR with solution.

soumyamahunt commented 11 months ago

While for your use case it sounds appropriate to make CodingKeys public, I don't think making this behaviour default will be appropriate.

CodingKeys are internal implementation and library authors should have control whether they want it to be exposed as public API.

This can be added as an additional option in Codable to choose the access level.

andriyslyusar commented 11 months ago

Implementing additional option in Codable would work as well. In defense of automatically inheriting access modifier, in case you make object public, CodingKeys are quite minor implementation detail and can't be override due it is an enum.

soumyamahunt commented 11 months ago

In defense of automatically inheriting access modifier, in case you make object public, CodingKeys are quite minor implementation detail and can't be override due it is an enum.

I agree it won't be overridable, my concern is once you make this implementation public any change made to CodingKeys will potentially be a breaking change for consumers of libraries. Hence I want the library authors to control this behaviour rather than MetaCodable deciding for them.

andriyslyusar commented 10 months ago

This can be added as an additional option in Codable to choose the access level.

Maybe better idea would be to add additional parameter to @CodingKeys to indicate access level, e.g. @CodingKeys(.PascalCase, accessLevel: .public). The default implementation would have .internal to avoid breaking backward comparability.

soumyamahunt commented 10 months ago

Maybe better idea would be to add additional parameter to @CodingKeys to indicate access level, e.g. @CodingKeys(.PascalCase, accessLevel: .public). The default implementation would have .internal to avoid breaking backward comparability.

This wouldn't be a good idea considering I am adding enum support, and @CodingKeys can be applied per enum-case. The accessLevel option will be added to @Codable as it is applied once per type. And yes default option will preserve current behaviour.