-
Notifications
You must be signed in to change notification settings - Fork 533
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
Codec #1151
Codec #1151
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1151 +/- ##
==========================================
- Coverage 86.39% 86.32% -0.07%
==========================================
Files 83 88 +5
Lines 2837 2962 +125
Branches 119 122 +3
==========================================
+ Hits 2451 2557 +106
- Misses 386 405 +19
Continue to review full report at Codecov.
|
doobie has |
I've resisted adding this thing for years, but I've finally been convinced that having
Codec
around for more convenient definitions (and faster semi-automatic derivation) is a good idea. This PR builds on #1150 (which is motivated by this change but should stand on its own) and includes @OlivierBlanvillain's change from #301. It doesn't build on @lorandszakacs's #811 at the moment, but I'll probably pull some tests from there.Note that the intention is that
Codec
should only be used to make defining instances more convenient, and not as a constraint. The core module provides noCodec
instances for any standard library types, and there is no machinery for summoningCodec
instances given an encoder-decoder pair. Fully-automatic generic derivation does not (and probably will not) provideCodec
instances, although semi-automatic derivation is supported in both the vanilla circe-generic form and with configuration in circe-generic-extras.The motivation is to speed up semi-automatic generic derivation (it should be not too far off twice as fast as deriving separate encoders and decoders,
but I've not actually done any benchmarking yet) and to avoid forcing users to write out member names twice when usingforProductN
.Update: I put together a file with 200 case classes and either
deriveCodec
or aderiveDecoder
/deriveEncoder
pair in the companion class, and after half a dozen runs of each on Scala 2.12.8, the newderiveCodec
approach consistently compiles in 20-21 seconds, while the old approach takes 35-36 seconds. So about 42% faster for that example case, which is actually a little better than I expected.The implementation currently supports writing this:
…or this:
…instead of this:
…or this:
It still needs tests and better docs and probably some clean-up.