chimney
chimney copied to clipboard
WIP Resolving TransformerF and Transformer ambiguity
Sometimes there is necessary to define TransformerF and Transformer rules that have intersected signatures. Current mechanism of TransformerF try to find both Transformer and TransformerF instances and it's not able to define priority using common Scala implicit priority hacks. It seems logical to me to choose Transformer instance as more priority and don't fail with compilation error on ambiguity. but if it's not possible because it breaks backward compatibility, maybe we can define special flag for this (but I'm not sure about adding this flag to FlagsDsl, because it can be used only for intoF).
Example of ambiguity is presented in tests, Coercible is analog of type class from newtype lib.
WDYT, @krzemin ?
Codecov Report
Merging #197 (459d38d) into master (577707a) will increase coverage by
0.00%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## master #197 +/- ##
=======================================
Coverage 99.55% 99.55%
=======================================
Files 25 25
Lines 674 679 +5
Branches 72 77 +5
=======================================
+ Hits 671 676 +5
Misses 3 3
Impacted Files | Coverage Δ | |
---|---|---|
...ney/internal/macros/TransformerConfigSupport.scala | 100.00% <100.00%> (ø) |
|
...nd/chimney/internal/macros/TransformerMacros.scala | 99.24% <100.00%> (+<0.01%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 577707a...459d38d. Read the comment docs.
@krzemin, it would be so nice to see this feature 🙏
Thank you for you contribution! Currently we are working on replacing TransformerF with a build-in structure for validated/failing transformations in https://github.com/scalalandio/chimney/pull/235. You can check the PR and give us an early feedback on its current behavior.