Add toIorT On EitherT #4108
Add toIorT On EitherT #4108
Conversation
Similar to `toEither` on `IorT`.
Co-authored-by: Ross A. Baker <ross@rossabaker.com>
|
I'd suggest adding a test for this new method into |
|
|
||
| /** Convert this `EitherT[F, A, B]` into an `IorT[F, A, B]`. | ||
| */ | ||
| def toIorT(implicit F: Functor[F]): IorT[F, A, B] = |
There was a problem hiding this comment.
I am not sure about the name. For example, a conversion to OptionT has a name just toOption (no T at the end). Should we follow the same convention here and name it as just toIor instead?
There was a problem hiding this comment.
@satorg hmm. I had noticed something similar on IorT with toEither: EitherT[F, A, B]. I had initially assumed this was a typo, but maybe it is an intentional convention. It seems strange to me, as there are two distinct ways view an EitherT[F, A, B] as an optional value, OptionT[F, B] and F[Option[B]] and I could see having both toOptionT and toOptionF. It seems we are a bit inconsistent right now.
For example, in IorT.scala we have fromEither, which operates on Either[A, B] as opposed to EitherT[F, A, B] and fromEitherF which operates on F[Either[A, B]].
It seems like if we want to standardize on a convention which can work with A, F[A], and G[F, A] (where G is some transformer type), then we have to go with the F and T suffixes.
Thoughts?
There was a problem hiding this comment.
@isomarcte I'm not that certain about the reasoning behind that convention, but I guess that it just does not make a lot of sense to have both toOptionT returning OptionT and toOptionF returning F[Option[...]], because OptionT implies F[Option[...]] already via its value field. And seems the same is applicable for EitherT and IorT.
There was a problem hiding this comment.
@satorg I'll update it. It does seem to be the convention.
|
@satorg test added |
There was a problem hiding this comment.
Good catch, @satorg. I don't like the convention, but it's good to follow it.
Similar to
toEitheronIorT.