Open andriyslyusar opened 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.
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.
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.
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.
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.
Right now
@Codable
macro will generate CodingKeys with internal access level.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.