Http4s: Conflicting Implicits orNotFound

[ChristopherDavenport]

This leads to conflicting implicits in combination with implicits and the dsl for .orNotFound. So we should likely pick one place to be the point of reference for that method and remove it from the other

I'm inclined to favor its removal from the dsl. And have this explicitly come in from implicits.

[rossabaker]

Http4sDsl extends Http4s, which is a bit of an anachronism: most libraries do the same with ${project}.implicits._. I'm strongly in favor of the Http4s trait going away.

If Http4sDsl no longer provides this syntax via Http4s, we potentially double the import tax. If it does provide the syntax, it becomes confusing if anyone imports both org.http4s.implicits._ and Http4sDsl.

I think the use cases are different enough that I agree with @ChristopherDavenport's suggestion.

[aeons]

Explicitly from the implicits sounds like a plan. :)

It will probably double the questions in gitter on where to get .orNotFound from, though.

[rossabaker]

All the more reason to finally start that FAQ!

[aeons]

I've been looking at this a bit.

We have this pattern in several places:

class X { ... }
object X extends XInstances { ... }
trait XInstances {
  // Instances for Show, Order, Eq, etc.
}

These XInstances are then mixed into the Http4sInstances trait which is then mixed into the Http4s trait. Won't they be found automatically, since they are in the companion object of the type itself? If so, just removing the trait and inlining the instances in the companion object should work, right?

We also mix in some functions from Uri and QValue. IMO those might as well be imported directly or called from the object, ie. Uri.uri or QValue.q.

Lastly, we mix in the different Entity{En,De}coder instances, so you can do binary[IO] to get the EntityEncoder for binary. Here, I think having a specific import or just calling them on the object would make sense as well. This is the same approach Circe uses (I think).