Implement optional implicit allowing usage of circe decoders without EntityDecoder definition #1917
Conversation
…EntityDecoder definition
I think this is useful, but it's worth mentioning two reasons that this is not a default, and maybe even worth mentioning this in the docs.
If that doesn't scare people off, this technique is often useful. I don't see any reason not to do an Encoder where we do the Decoder. And in that case, it'd be nice to not require two imports. |
The first point is already mentioned in https://github.com/http4s/http4s/pull/1917/files#diff-dcf0079785763cffc8cb901dad9f0628R205 Should I clarify it? And I doubt that incoherent instances are possible in the same scope: they result in ambiguous implicits error. |
I looked at the diff, and not the wider context. You're right, I think the first point is covered well enough. As for the second issue, a lexically scoped instance (e.g., |
I tried testing the implicit resolution and found that it does not compile at all. Somehow |
/** | ||
* Derive [[EntityDecoder]] if implicit [[Decoder]] is in the scope without need to explicitly call `jsonOf` | ||
*/ | ||
trait CirceEntityDecoder { |
ChristopherDavenport
Jun 14, 2018
Member
Why do this as a trait and then an object which extends said trait? Why not just place this in the object?
Why do this as a trait and then an object which extends said trait? Why not just place this in the object?
Leammas
Jun 14, 2018
•
Author
Contributor
I use it in combined object org.http4s.circe.CirceEntityEncDec
now and there's a small probability that someone may find it useful for its own generic code.
I use it in combined object org.http4s.circe.CirceEntityEncDec
now and there's a small probability that someone may find it useful for its own generic code.
I added implementation allowing usage of |
@@ -0,0 +1,3 @@ | |||
package org.http4s.circe | |||
|
|||
object CirceEntityEncDec extends CirceEntityDecoder with CirceEntityEncoder |
rossabaker
Jun 15, 2018
Member
I think Codec
is a more common term than EncDec
. How about CirceEntityCodec
?
I think Codec
is a more common term than EncDec
. How about CirceEntityCodec
?
Leammas
Jun 15, 2018
Author
Contributor
Yeah, sounds better.
Yeah, sounds better.
and decoding derivation: | ||
|
||
```tut:book | ||
org.http4s.circe.CirceEntityEncDec._ |
rossabaker
Jun 15, 2018
Member
This tut broke with an ambiguous implicit. We need to sort this out. Running sbt doc/tutQuick
should test it locally.
This tut broke with an ambiguous implicit. We need to sort this out. Running sbt doc/tutQuick
should test it locally.
Leammas
Jun 15, 2018
Author
Contributor
Woops, the exact thing I wrote: we can't use both CirceEntityEncoder
and plain json. I restricted the scope, but I'm not sure if it's the right way. Maybe I should not use tut:book
there at all?
Woops, the exact thing I wrote: we can't use both CirceEntityEncoder
and plain json. I restricted the scope, but I'm not sure if it's the right way. Maybe I should not use tut:book
there at all?
rossabaker
Jun 16, 2018
Member
I think it's good to ensure that the import continues to compile, and you note the risk of ambiguity below. I played with invisible braces around it, and it doesn't work. I think the best we can do.
I think it's good to ensure that the import continues to compile, and you note the risk of ambiguity below. I played with invisible braces around it, and it doesn't work. I think the best we can do.
I can backport this into release-0.18 if we want to squeeze this into the release with the pool fix. |
Backport #1917 (CirceEntityCodec) to 0.18.x
I've discussed the necessity of this implicit in gitter. Appeared useful.