Explore the possibility of "functional definitions" in DI

[utybo]

The idea is to be able to define DI components as functions. This would unlock more advanced use cases, an obvious one being easier definition of simple web controllers and Ktor modules.

Usage

Here's an example of what this could look like.

Tegral Web Controllers

For example:

class GreeterService {
    fun greet(name: String): String {
        return "Hello, $name!"
    }
}

@TegralDiFundef
fun Application.openApiModule() {
    describe {
        title = "My greeter API"
    }
}

@TegralDiFundef
fun Routing.controller(gs: GreeterService) {
    get("/greet/{name}") {
        call.respondText(gs.greet(call.parameters["name"]!!))
    }
}

fun main() {
    tegral {
        install(OpenApiFeature)
        put(::openApiModule)
        put(::controller)
    }
}

Tegral DI

class GreeterService {
    fun greet(name: String): String {
        return "Hello, $name!"
    }
}

@TegralDiFundef
fun greetWorld(gs: GreeterService) {
    return gs.greet("World")
}

fun main() {
    val env = tegralDi {
        put(::GreterService)
        put(::greetWorld)
    }
    val fundef = env.getOrNull<Fundef>(ofFunction(::greetWorld))
    fundef.function // == ::greetWorld
    fundef() // == greetWorld(...)
}

Pros, cons and remarks

Pros

Indentiation

Saves an indentation space for controllers and modules and significantly simplifies their definition.

class HelloController : KtorController() {
    override fun Routing.install() {
        get("class") {
            call.respondText("Hello World!")
        }
    }
}

@TegralDiFundef
fun Routing.helloController() {
    get("fun") {
        call.respondText("H:ello World!")
    }
}

fun main() {
    tegral {
        put(::GreterService)
        put(::HelloController)
        put(::helloController)
    }
}

Ktor modules

• Is similar to what the Ktor docs recommend with Ktor modules. This could also make the transition from module-based Ktor to Tegral easier

Misc.

• Optional injection (scope.optional()) can easily be supported by using default parameters! (probably with nullable support, so A? = null in a parameter would be the same as env.getOrNull<A>())

Cons

Qualifiers

• Retrieving qualified components becomes a huge mess
  • Either provide qualifier info via annotations. Not super feasible.
  • Maybe a special DSL for it?

class GreeterService {
    fun greet(name: String): String {
        return "Hello, $name!"
    }
}

@TegralDiFundef
fun greetWorld(gs: GreeterService) {

}

fun main() {
    val env = tegralDi {
        put(::GreterService, named("Hellofy"))
        put(
            (::greetWorld).toFundef {
                qualifyParameter("gs", named("Hellofy"))
            }
        )
    }
}

• Collides with the current put syntax, becomes constructors are considered functions when using reflection. Either
  • Find a way to differentiate between functions and constructors: this is possible using <KFunction object>.javaConstructor != null.
  • Force the use of an annotation permanently for functions (there would still be annotations at first while this is an experiment)

Remarks

• In order to respect the "principal" of safe injections, functional definitions would have to retrieve all of the required objects within an init block.

Todo list

• Fundef: Initial release #73
  • Implement basic support in Tegral DI
  • With experimental annotation
  • With a special function putFundef
• v+1: Fundefs, round 2! #87
  • Support in Tegral Web Controllers, requires Add a way to configure features #72
  • Merge putFundef into put
• v+2:
  • Drop annotation requirement see below
  • Stabilization and GA

[utybo]

Idea for the step 3 of this whole plan, I think it would be better if we use the following behavior.

In cases where we could have a fundef:

• If a @Fundef annotation is present, register as a fundef,
• provide, in the tegralDi {} block, some function defineAsFundefIf { ... } that takes the incoming function and, if it returns true true, will register it as a fundef as if a @Fundef annotation was present. Multiple defineAsFundefIf can be added and, if any of them evaluates to true, the function will be registered as a fundef
• keep the current behavior (only accept functions with no parameters or 1 argument of type InjectionScope)