@AddAccessor annotation to automate accessor creation for included graphs

[bubenheimer]

I'd like to propose a new annotation for Metro, for now let's call it @AddAccessor. The annotation would trigger addition of a public accessor in a dependency graph.

An oversimplified example:

@DependencyGraph
interface AppGraph {
  @Provides
  @AddAccessor
  fun provideMessage(): String = "Hello, world!"
}

This would result in something like this being generated:

interface MessageAccessor {
  val message: String
}

class AppGraphImpl : AppGraph, MessageAccessor {
  // …
}

This is useful for included graphs (a.k.a. Dagger’s component dependencies): only public accessors from the included graph are available as bindings in the including graph.

Without this annotation there can be a lot of boilerplate for adding public accessors when there are a lot of desired bindings in the included graph.

From my perspective the annotation is a natural next step for dealing with included graphs, so I believe it’s of general value.

I have this implemented as a custom Anvil processor. Would be nice to get it integrated into Metro natively, to avoid the slow KSP route and make it more widely available.

The gist of the Anvil annotation is this:

@Repeatable
annotation class AddAccessor(
    val scope: KClass<*> = Unit::class
)

It’s repeatable, because graphs can be included “recursively”, so more than one level of included graph may need to expose the accessor. (If this sounds too unconstrained, 99% of my cases do not need @Repeatable or specifying a scope explicitly, and just use the default scope approach below, so it would be ok to just add a bit of manual work for the remaining 1%.)

The Anvil processor generates a custom interface plus @ContributesTo to include it in the graph.

There is a little more design detail I can add if this proposal finds support. In particular, the explicit scope can be omitted when it is clear from the context, i.e. a @ContributesTo on an enclosing element, which is the common case.

This could possibly also be an alternative approach for contributed graph extensions.

Here is a more comprehensive example:

@BindingContainer
@ContributesTo(IncludeScope2::class)
object Container {
    @Provides
    @AddAccessor // defaults to IncludeScope2
    fun binding1(input: OtherType1): SomeType1 { /*...*/ }

    @Provides
    @AddAccessor
    @AddAccessor(IncludeScope1::class)
    fun binding2(input: OtherType2): SomeType2 { /*...*/ }
}

@DependencyGraph
interface AppGraph {
  // demonstrate that this binding is available here
  val value: SomeType2

  @DependencyGraph.Factory
  fun interface Factory {
     fun create(@Includes includedGraph: IncludedGraph1): AppGraph
  }
}

@DependencyGraph(IncludeScope1::class) 
interface IncludedGraph1 {
  @DependencyGraph.Factory
  fun interface Factory {
     fun create(@Includes includedGraph: IncludedGraph2): IncludedGraph1
  }
}

@DependencyGraph(IncludeScope2::class)
interface IncludedGraph2

[ZacSweers]

I'm not a fan of this on the face of it as it conflates the purpose of providers and seems like a niche use-case. It would also be quite non-trivial to implement due to the nature of how FIR works (there is no notion of processing rounds that would allow generation of new declarations). Using KSP seems like the right approach for this.

[bubenheimer]

Thanks for the feedback and opinions.

niche use-case

I don't know if you've worked with component dependencies much, you may have, but I guess it depends on how you use them. From my perspective: component dependencies are held back by the boilerplate problem that this annotation aims to address, and they are likely underutilized for this reason, in favor of patterns that are not the right conceptual fit, but faster to implement.

conflates the purpose of providers

The annotation is separate from @Provides and @Inject, so at least in the intended context of @ContributesTo this notion seems weak. Open to alternative suggestions.

Implementation concerns may be valid, can't speak to those. But would it actually be harder to implement and hackier than contributed graph extensions?

[ZacSweers]

I have worked with component dependencies plenty :)

The annotation may be different but the declaration is the same.

Yes, the implementation would be non-trivial because it requires generating code in FIR that would then be processed by another FIR generator, and that's not possible currently in the compiler. Take a look at how function injection is implemented if you want to get a sense of how this works, it has to all be pushed into the same generator that handles regular class injection.