-
-
Notifications
You must be signed in to change notification settings - Fork 94
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
Automatic Coproduct Rename from/to Protobuf GeneratedEnum #480
Comments
Hey 👋, great thanks for suggestion! I agree that such feature would be quite useful, but I would hesitate to enable it by default - virtually every feature that we ever added and had it turned on by default ended up with a bug report from someone who expected the code to fail/require manual intervention. I don't think that all such cases make sense (if one ends up with more configs than code they are helping to replace, it kind of misses the point), but this one feels like something that could be opt-in. I recently started developing a feature allowing to customize how fields and subtypes are compared. It would address quite similar request for fields (#89) but also add an ability to customize comparison of subtypes/enum values. If it was merged then adding enum support could be done e.g.
(alternatively, there could be several conventions prepared inside Would such solution work for you? I am not sure when I finish working on it. I started that mainly to take a break from some more mundane tickets that has to be implemented before 1.0.0-RC1, but I also have less time on mu hand AT. |
I think right now, it's mostly grind:
It isn't necessarily trivial, low-hanging fruit, but for the kind of work that happens in this project it's relatively simple - if you want to try, you can create a branch off #478 and see how it goes. :) |
I continued in https://github.com/saeltz/chimney/tree/custom-name-comparator-saeltz. All usages have been replaced with |
Thank you! I've created a PR out of your changes. |
Added in 1.0.0-M3 |
I think it might be useful to have something OOTB in Chimney for some very common cases like Protobufs and Java integrations, however I need to point out that
the whole point of #489 the PR is that everyone can add a custom comparator in their own codebase. The code in macros is as tricky as you see because we are not relying on pattern-matching on a |
Checklist
TransformerF
s) orunsafeOption
flagsDescribe the desired behavior
#409 proposes to allow renaming of coproducts. I think this is a good idea if one wants to transform from one enum to another with only the names being different.
I propose to allow for an automatic renaming if using Protobuf. If you follow the official Protobuf guidelines, enums are prefixed with the name of the enum and all uppercase, e.g.
In Scala (3), one wants to follow the best practices and use an enum with different names, e.g.
This requires to define a custom transformer with one
.withCoproductInstance
per case. Introducing.withCoproductRenamed
would simplify the code a bit but would still require a custom transformer with all cases.I propose to have automatic renaming from Protobuf GeneratedEnum to Scala 3 enum with CamelCase. Possibly as an opt-in with the special protobuf import.
Additional context
I know this is heavily opinionated. I would love to get to know to solve this problem differently. If you're willing to have this feature, I'd be able to spend some time on it. I think it'd need to be added in
TransformSealedHierarchyToSealedHierarchyRuleModule.scala
.The text was updated successfully, but these errors were encountered: