-
Notifications
You must be signed in to change notification settings - Fork 29
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
Support for zio layers #49
Conversation
331bfe4
to
6610927
Compare
looks good! what would be the problem with making this the default? |
Is I probably encountered a similar case before, if you have a small test case I should be able to help |
I'm afraid that my changes may lead to not equivalent types in common case. It must work for zlayers from zio but I'm not sure about common case. I don't know about other cases when compiler can generate such nested
My test already includes this example. For example, if I specify type explicitly val service1: ULayer[Has[Service1]] = ZLayer.succeed(new Service1 {})
val service2: ULayer[Has[Service2]] = ZLayer.succeed(new Service2 {})
val service3: URLayer[Has[Service1], Has[Service3]] = ZLayer.fromService { (_: Service1) => new Service3 {} }
val service4: ULayer[Has[Service4]] = ZLayer.succeed(new Service4 {}) then compiler generates following tree for RefinedType(List(
RefinedType(List(
TypeRef(ThisType(zio), zio.Has, List(TypeRef(ThisType(ru.tinkoff.mvno.callerid.layers), ru.tinkoff.mvno.callerid.layers.Service1, List()))),
TypeRef(ThisType(zio), zio.Has, List(TypeRef(ThisType(ru.tinkoff.mvno.callerid.layers), ru.tinkoff.mvno.callerid.layers.Service2, List())))
), Scope()),
TypeRef(ThisType(zio), zio.Has, List(TypeRef(ThisType(ru.tinkoff.mvno.callerid.layers), ru.tinkoff.mvno.callerid.layers.Service3, List())))
), Scope()) Comparing this tree with tree from my initial comment we can see that depth of But it requires explicit types which we may try to avoid. |
well since you're checking for the presence of the zio type before the analysis I don't see what the harm is |
Hmm, I was going to remove |
if the tests are green, ship it! |
@danilbykov Am I right to assume that you wanted to change that thing before merging? |
Sorry, I thought that it means I should not change current version.
I removed |
Oh, I can see how that might have been ambiguous. sorry! |
Using ZLayers from zio leads to unreadable compilation messages when environment misses some layer. This plugin can greatly improve error messages.
RefinedFormatter
already does most of work but small changes are needed.RefinedFormatter
collects traits only from top level while zlayers can have nestedRefinedType
s. Here is example from my testIt has several levels of
RefinedType
s and services are on bottom level. This is why I added classDeepRefined
.There is another issue with this syntax tree which breaks error reporting. Compiler defines type of services as
zio.Has[AnyRef with layers.Service1]
which is equivalent tozio.Has[layers.Service1]
. So I was needed to handle this case insideDeepRefined
and removeAnyRef
insidezio.Has
.What do you think about these changes? Can I add some new option for plugin which allows to replace default
Refined
byDeepRefined
?