Is your feature request related to a problem? Please describe.
A recent release has removed the higher-kinded-type (HKT) interface when generating services (i.e. it removed the option to write Service.MethodPerEndpoint as Service[Future]). This change has excluded an existing use-case described in the comments on that commit. For brevity I will paraphrase it here:
Not everyone prefers to use twitter Futures, and the HKT interface allows you to easily change to a different F. i.e. we can turn a Service[twitter.util.Future] into a Service[scala.concurrent.Future] by providing the function* twitter.util.Future => scala.concurrent.Future. That allows us to work directly in our chosen F until we need to convert everything back to twitter Futures for finagle.
Describe the solution you'd like
There should be an option to generate the HKT interface for services. Either through a plugin or a flag. The main impetus behind the original commit seems to have been to reduce the total amount of generated code. Thus a plugin/flag would allow most to benefit from the reduced code volume, and allow others to use the interface if needed.
Footnotes:
- That's technically a "Natural Transformation" (
~>), not a function (=>)
Is your feature request related to a problem? Please describe.
A recent release has removed the higher-kinded-type (HKT) interface when generating services (i.e. it removed the option to write
Service.MethodPerEndpointasService[Future]). This change has excluded an existing use-case described in the comments on that commit. For brevity I will paraphrase it here:Not everyone prefers to use twitter
Futures, and the HKT interface allows you to easily change to a differentF. i.e. we can turn aService[twitter.util.Future]into aService[scala.concurrent.Future]by providing the function*twitter.util.Future => scala.concurrent.Future. That allows us to work directly in our chosenFuntil we need to convert everything back to twitterFutures for finagle.Describe the solution you'd like
There should be an option to generate the HKT interface for services. Either through a plugin or a flag. The main impetus behind the original commit seems to have been to reduce the total amount of generated code. Thus a plugin/flag would allow most to benefit from the reduced code volume, and allow others to use the interface if needed.
Footnotes:
~>), not a function (=>)