In order to avoid the mix-in, you should rely on ad-hoc polymorphism, i.e. 
use implicits to get an evidence of a Marshaller for your type. 
`Marshaller` is basically a typeclass so stick to that pattern in your 
solution. 

El jueves, 15 de junio de 2017, 23:21:17 (UTC+2), Jeff escribió:
>
> That gave me a lot of inspiration, much thanks. I've adapted that into the 
> following pattern:
>
> abstract class RestaurantRoutes[F[_]: Monad](algebra: 
> RestaurantAlgebra[F]) extends MonadToResponseMarshaller[F] {
>   import algebra._
>
>   def route: Route =
>     path("api" / "v4.0" / "restaurant" / IntNumber) { rid =>
>       get {
>         complete(getRestaurantById(rid).map(_.toString))
>       }
>     }
> }
>
> trait MonadToResponseMarshaller[F[_]] {
>   implicit def monadMarshaller[A: ToResponseMarshaller]: 
> ToResponseMarshaller[F[A]]
> }
>
> trait FutureOfOptionToResponseMarshaller { this: 
> MonadToResponseMarshaller[FutureOfOption] =>
>   import CatsMarshallers._
>
>   def monadMarshaller[A: ToResponseMarshaller]: 
> ToResponseMarshaller[FutureOfOption[A]] =
>     implicitly
> }
>
> trait Routes {
>   import cats.instances.future._
>
>   def routes(implicit ec: ExecutionContext): Route = {
>     val restaurant = new RestaurantRoutes(new 
> RestaurantFutureInterpreter()) with FutureOfOptionToResponseMarshaller
>
>     restaurant.route
>   }
> }
>
> trait CatsMarshallers {
>   implicit def optionTMarshaller[F[_], A, B](implicit m: 
> Marshaller[F[Option[A]], B]): Marshaller[OptionT[F, A], B] =
>     Marshaller { implicit ec => v => m(v.value) }
> }
>
> object CatsMarshallers extends CatsMarshallers
>
> This seems fairly clean and composable, but I'm wondering if there's a way 
> to prevent having to mix-in FutureOfOptionToResponseMarshaller every time.
>
> On Tuesday, June 13, 2017 at 10:30:53 PM UTC-7, Juan José Vázquez Delgado 
> wrote:
>>
>> I've faced a similar situation recently working on this example 
>> <https://github.com/juanjovazquez/scala-petclinic>. It's not easy but is 
>> definitely feasible. The bottom line is: run your own marshaller.
>>
>> El martes, 13 de junio de 2017, 18:44:01 (UTC+2), Jeff escribió:
>>>
>>> I am trying to learn tagless final style to remove concrete monads (ie 
>>> futures) from my code. I have come up with the following strawman 
>>> application (using cats)
>>>
>>> class RestaurantRoutes[F[_]: Monad](algebra: RestaurantAlgebra[F]) {
>>>   import algebra._
>>>
>>>   def route: Route =
>>>     path("api" / "v4.0" / "restaurant" / IntNumber) { rid =>
>>>       get {
>>>         complete(getRestaurantById(rid).map(_.toString).value)
>>>       }
>>>     }
>>> }
>>>
>>> object RestaurantRoutes {
>>>   def apply()(implicit ec: ExecutionContext): 
>>> RestaurantRoutes[FutureOfOption] = {
>>>     import cats.instances.future._
>>>
>>>     new RestaurantRoutes(new RestaurantFutureInterpreter())
>>>   }
>>>
>>> }
>>>
>>> the final type of 
>>>
>>> getRestaurantById(rid).map(_.toString).value
>>>
>>> is a
>>>
>>> Future[Option[String]]
>>>
>>> However, I can't seem to figure out to get that marshalled. A marshaller 
>>> exists for all those types, and had I had concrete types intstead of F[_], 
>>> it would have worked. What is the best way to handle this to prevent 
>>> implementation details from leaking in?
>>>
>>> Thanks
>>> Jeff
>>>
>>

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to