Macwire does not consider outer trait members to be candidates for wiring

[gmethvin]

If I have a trait with an inner trait like this:

trait FooComponents {
  lazy val fooService: FooService = wire[FooService]

  trait FooRequestScopedComponents {
    def request: RequestHeader
    def fooController: FooController = wire[FooController]
  }
}

Macwire (2.3.0) is unable to see the fooService in the outer scope and will report an error like FooComponents.scala:20: Cannot find a value of type: [services.FooService]. Writing the code manually works fine.

My motivation here is to try to create a set of "request components", which are instantiated per-request and can have a dependency on the request. I prefer not to use a traditional "request scope" that uses thread locals because that can be hard to manage across thread boundaries in async frameworks like Play, and it seems far less intuitive than normal dependency injection.

I have a basic example Play app showing the approach here: https://github.com/gmethvin/play-scala-macwire-di-example/blob/50f4771/app/GreetingApplicationLoader.scala. I'd like to be able to replace many of those manual constructor calls with wire calls though.

[gmethvin]

Macwire could also have an option to consider outer trait members as conflicting with inner trait members of the same type. In other words, it would be an error to define the same type in both the inner and the outer scope. This would potentially prevent scoping-related errors, and would be consistent with what Guice does with child injectors.

[gmethvin]

We could also integrate something like https://github.com/adamw/scala-macro-aop, and generate delegates for the outer scope to the inner scope. That would be the most robust solution for scoped dependencies, since if a trait did not depend on the request it could be easily used in either scope.

[adamw]

I don't think it's possible to access the enclosing class of the enclosing class in a macro (there's only Context.enclosingClass, but it's not recursive)