Binding Decorators

[chrisbanes]

Description

We had this feature in our custom DI framework at Twitter, and it was super handy for large codebases.

Here's the use case that I'm thinking, but I'm 100% sure that there's more. We have a Logger with takes a tag, and in every class we either:

• Create a copy of the logger: val classLogger = logger.withTag("MyClassName")
• Or just pass it in at the calls logger.d(TAG)

It would be nice if we could attach some kind of decorator so that the injected logger is pre-decorated with the class name as tag.

The API could be something like the following:

annotation class BindingDecorator(val type: KClass<Any>)

interface Decorator<T> {
  fun decorate(context: BindingContext, value: T): T
}

Then to create and attach a decorator:

annotation class LoggerDecoration

@Inject
@BindingDecorator(LoggerDecoration::class)
class LoggerDecorator : Decorator<Logger> {
  override fun decorate(context: BindingContext, source: Logger): Logger {
    return logger.withTag(context.callee.simpleName)
  }
}

Then, every Logger injected into a class would be automatically decorated with the class name.

This is just one example. Others could include:

• Tracing. A tracing decorator which automatics add Trace sections around binding functions
• I'll think of more 😄

[efemoney]

Spring (framework) has a slightly different concept called InjectionPoint that solves much of the same problems but without the downsides (if any?) and it ties into familiar DI concepts. Spring uses reflection but metro being a compiler plugin makes the concept OP.

The way it works is that at a types "injection point" ie where the type is requested/injected, you add a "virtual" / "intrinsic" dependency that gives basic information about where/how that type is being injected & the type can use that information within itself.

The information could be whether or not its a value parameter or property injection? What is its enclosing class? And maybe any annotations on the injection.

Here's an example from one of my services. In my case I allow my users to annotate the injected parameter or field with a custom LogName or if they dont, I just use whatever class the logger is being injected in.

@Provides 
// OR @Inject on Logger constructor ... also, cannot have scoping
fun logger(injectionPoint: InjectionPoint): Logger {
  val name = injectionPoint.getAnnotation(LogName::class.java)
  return if (name != null) getLogger(name.value) else {
    getLogger(
      injectionPoint.methodParameter?.containingClass
        ?: injectionPoint.field?.declaringClass
    )
  }
}

As an example, assuming we have the above provision declared:

// Logger is injected with: 
// InjectionPoint [
//   type=value-parameter, 
//   name=logger,
//   method=<init>,
//   enclosingCls=MyClass, ...
// ]
@Inject
MyClass constructor(val logger: Logger)

and another case:

// Logger is injected with 
// InjectionPoint [
//   type=value-parameter, 
//   name=log,
//   method=providesOther
//   enclosingCls=MyProvisions, ...
// ]

MyOtherClass(val logger: Logger)

@Module
interface MyProvisions {
  @Provides
  fun provideOther(log: Logger) = MyOtherClass(logger)
}

It goes without saying that for any usage of InjectionPoint, that particular binding can not be scoped (and the provision method/constructor will be called everytime)

Just sharing as an alternative to discuss/consider.

[ZacSweers]

re: scoping, @chrisbanes these could never be scoped in your case either right? Or would you envision the scoped instance to be decorated too? Or the injected instance to be a decorated instance around some scoped source instance?

[chrisbanes]

For simplicity's sake I'd say to stay consistent with Spring, and make it so that the decorator/binding can not be scoped, but the receiver (MyClass in the example above) can be scoped.