-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move Op from parameter to member in smithy4s.Service #567
Conversation
Similarly to what happened with `cats.Parallel`, the Operation type of `smithy4s.Service` can be moved from type-parameter to type-member, which helps implicit search.
implicit val serviceInstance: Service[Alg, Op] = this | ||
val service = this | ||
trait Service[Alg[_[_, _, _, _, _]]] extends FunctorK5[Alg] with Service.Provider[Alg] { | ||
type Operation[E, I, O, SI, SO] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allows for a long name :D (not that it was not allowed of course, just that the long version in the type parameter as just so annoying
sooo why didn't CI fail on any of the last commits? |
The CI, as currently configured, doesn't run unless the PR is targeting main (afaik) |
we should probably change that, then :) |
2f5d092
to
f6dcb65
Compare
This reverts commit 768ca6e.
Problem was that PR trigger was using the |
trait Service[Alg[_[_, _, _, _, _]], Op[_, _, _, _, _]] extends FunctorK5[Alg] with Service.Provider[Alg, Op] { | ||
implicit val serviceInstance: Service[Alg, Op] = this | ||
val service = this | ||
trait Service[Alg[_[_, _, _, _, _]]] extends FunctorK5[Alg] with Service.Provider[Alg] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the changes derive from this line : the Op
is moved from type-parameter to type-member.
type Endpoint[I, E, O, SI, SO] = smithy4s.Endpoint[Operation, I, E, O, SI, SO] | ||
type Interpreter[F[_, _, _, _, _]] = PolyFunction5[Operation, F] | ||
type FunctorInterpreter[F[_]] = PolyFunction5[Operation, kinds.Kind1[F]#toKind5] | ||
type BiFunctorInterpreter[F[_, _]] = PolyFunction5[Operation, kinds.Kind2[F]#toKind5] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the type aliases above are path-dependant (by virtue of depending on the Operation abstract type member) , it means we can ascribe service.Endpoint
, service.Interpreter
, etc etc. This allows to simplify up a number of verbose ascriptions here and there.
service, | ||
service.toPolyFunction[Kind1[F]#toKind5](impl), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the implementation was prematurely turned into a polymorphic function
|
||
def apply[Alg[_[_, _, _, _, _]]](implicit ev: Service[Alg]): ev.type = ev | ||
|
||
type Aux[Alg[_[_, _, _, _, _]], Op[_, _, _, _, _]] = Service[Alg]{ type Operation[I, E, O, SI, SO] = Op[I, E, O, SI, SO] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the Aux
pattern allows to "recover" the type parameter that was moved, in locations where it matters
Similarly to what happened with
cats.Parallel
, the Operation type ofsmithy4s.Service
can be moved from type-parameter to type-member. This simplifies type signatures for a number of public methods, and helps implicit search in some cases.