Thoughts on adding "auto-injection" capabilities to ktx-inject?

[runt9]

First off, thank you so incredibly much for KTX, it's made my first foray into LibGDX in my favorite language an absolute blast!

I've spent the last decade doing full-stack development in Spring and so coming to using ktx-inject for my DI has been different than what I'm used to. I'm getting ready to rewrite most (all?) of my game to prepare the code base for future growth and one of the things that ended up on my list was seeing if there was a way to make DI a bit more automatic like I'm used to in Spring.

After jumping through some Google searches, it seems like the full package/annotation scanning way would add a lot of coding time and also have some startup overhead, so I went with just seeing what I could do to make it to where I didn't have to call a real constructor with many inject() calls so I didn't have to go and update the DI registry every time I added or removed an injected field from a class.

Here's the few lines of code I came up with and wanted to throw it out there as a potential option for ktx-inject, even though it's explicitly stated in the readme that it's reflection-free:

inline fun <reified Type : Any> Context.autoBindSingleton() = bindSingleton(autoInject<Type>())

inline fun <reified T> autoInject(): T {
    val constructor = T::class.constructors.first()
    val args = constructor.parameters.map { param -> injector.getProvider(param.type.jvmErasure.java)() }.toTypedArray()
    return constructor.call(*args)
}

This makes it to where in your injector.register { block, you simply call something like autoBindSingleton<ClassToBind>() and it will always inject the correct arguments even if you change the order, add or remove some, etc.

This would also open things up to a path-scanning possibility with Reflections, but that's a step I'm not sure I need right now. But I wanted to share the snippet and see if it might be useful for KTX?

I'm sure as I put this game together there will be many more snippets like this I could potentially contribute so expect to see my name around a bit :)

[czyzby]

First of all, thanks for the suggestion @runt9. As for automatic classpath scanning and similar features, I wanted to avoid them specifically because of the reflection usage and how it complicates the internal implementation. It certainly can be done for every platform, including GWT - you can check out my previous attempt at a cross-platform LibGDX DI framework here. Fair warning though, code quality is probably much lower there, as I was still inexperienced when I made the LML libraries.

I wanted to avoid reflection-based classpath scanning as it causes some problems outside of desktop applications. It basically requires custom code for each platform in order to work correctly, and some LibGDX backends (like GWT or iOS, if I recall correctly) require additional registration of classes that should be available via reflection, which kind of defeats the purpose of automatic classpath scanning in the first place. Not to mention that any third-party backends for platforms such as HTML likely won't support reflection at all, which makes porting even harder.

That being said, the snippet that you have posted would be a rather simple utility that wouldn't require any additional dependencies or much setup on user side. It would have to be rewritten with LibGDX reflection API, but other than that I could see it being useful to avoid repeating too many inject() calls. Still, this is something that KTX users should introduce consciously into their project, so maybe it's worth it to require an @OptIn annotation with a warning about LibGDX reflection quirks - similarly to how experimental coroutines APIs work.

[runt9]

Thank you for the quick reply!

Yeah the automated classpath scanning might come in handy but seems like more trouble than it's worth, especially when you get into the problem of targeting many platforms, as you mentioned. That said, along with the thought of something like this being an OptIn feature, would there be harm in starting down the route of a slightly more complex/heavyweight DI system for larger games that could be an additional module (probably mutually exclusive with ktx-inject)? I'm not sure how much actual value there is there over just adding this as an additional utility option to the existing inject, but it's just a thought.

Side note: I honestly didn't even realize LibGDX had to roll a reflection wrapper and hadn't looked into it at all. That said, it doesn't immediately look like it'd be too bad to redo things. If you think this is a valuable potential addition to KTX, I'd be more than happy to get setup in contributor mode and get a PR open for it :)

[czyzby]

I'm a bit conflicted, because I see the value in heavyweight DI with classpath scanning, but on the other hand it wouldn't fit KTX very well. The initial goal of KTX was to be like LibGDX, but in Kotlin - in that sense, even the current ktx-inject module does not fit all that much, as it introduces completely new functionalities rather than improvements for existing ones. Also, besides dedicated Kotlin wrappers like ktx-ashley or ktx-vis, KTX libraries have no additional dependencies, and none of them introduce any platform-specific code at the moment.

Extension methods using reflection is something I would like to see in ktx-inject, but I think an alternative DI project with classpath scanning on each platform should be a separate set of libraries. If this is something you'd like to create, I'll be happy to link it in ktx-inject README as an alternative. You can ask on #kotlin Discord channel if there's interest for that.

[czyzby]

For the record, reflection-based binding methods were added to ktx-inject in #379. Automatic classpath scanning will not be added as a feature, but you're welcome to contribute your own library (or a KTX extension) if you're planning on implementing something similar.