This message was deleted.

# arrow

[Slackbot]

This message was deleted.

[melatonina]

I guess that's just a fundamental JVM limitation. Type arguments are erased. If you expand the type aliases, the difference between the types that are extented is only matter of type arguments, otherwise it's just always EffectValidator. As a consequence the JVM signature is the same, and the methods are undistinguishable.

[Gopal S Akshintala]

Ya, is there any way I can get around it? I explored reified, but couldn’t figure out how to apply in this context

[melatonina]

I have no experience with this kind of code. Can you subclass the interface EffectValidator instead of using type aliases?

[melatonina]

I don't see how reified would help.

[Gopal S Akshintala]

I am thinking of making them extensions on ValidatedPartialOf and EitherPartialOf and pass repo as function parameter

[melatonina]

Can you work with these new types, instead?

interface EffectValidatorErrorAccumulation<F, E> : EffectValidator<F, ValidatedPartialOf<Nel<E>>, E>
interface EffectValidatorFailFast<F, E> : EffectValidator<F, EitherPartialOf<Nel<E>>, E>

[melatonina]

Extending the parameter type would be a good work-around, too.

[Gopal S Akshintala]

The interface approach removes the error, but I just realized, I can’t have failfast this way, as I am raising error on validatorAE and so bind() won’t give me the flatMap effect. So another problem on top this, I think I need a Monad Transformer 🤔

fun <F> EffectValidatorFailFast<F, ValidationError>.validateUserWithRules(user: User): Kind<F, Kind<EitherPartialOf<Nel<ValidationError>>, Boolean>> = fx.async {
    validatorAE.run {
        cityShouldBeValid(user).bind()
        loginShouldNotExit(user).bind()
    }
}