You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yeah, you're right that receiving it as a constructor param and using
it in the transK method is a bit repetitive.
However, since the interface we need to follow is the one from InterpTrans,
we need it in both places, as for now, since the transK method is
being used in other projects.
I've however thought of changing the InterpTrans more than
once, that meaning that since for all implementations of the
interpreter we'd need a value of the target's http client (apache's HttpClient, Akka's HttpExt...), I'd delete the trans
method from the typeclass and only use the transK method.
I'm not sure to understand the whole picture but here is my 2 cents :
/* Keep interpreter signature as simple as possible. Just a F type without any behavior.*/traitInterpTrans[F[_]] {
deftrans:HttpF~>F
}
/* Just an alias for Kleisli interpreter*/traitKleisliInterTrans[F[_], Client] extendsInterpTrans[Kleisli[F, Client, ?]]
/* Here is the trick : deal with legacy by using client in context to execute kleisli interpreter*/traitLegacyTrans[F, Client] extendsInterpTrans[F[_]] {
valclient:ClientvalkleisliTrans:KleisliInterTrans[F, Client, ?]
deftrans:HttpF~>F= kleisliTrans.transK andThen λ[Kleisli[F, Client, ?] ~>F](_.run(client))
deftransK:HttpF~>Kleisli[F, Client, ?] = kleisliTrans.trans
}
Hammock Interpreter have HttpClient as constructor parameter. So why use Kleisli[F, HttpClient, ?] in the internal machinery?
We could just use Async effect without any other layer.
The text was updated successfully, but these errors were encountered: