Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: allow creating custom qualifier annotations #176

Open
wants to merge 2 commits into
base: 2.0.0
Choose a base branch
from

Conversation

skyecodes
Copy link

@skyecodes skyecodes commented Oct 3, 2024

Following #108, I was wondering if it was possible to improve class-based qualifiers even more by being able to make our own qualifier annotations like so:

@Named
annotation class InMemoryLogger

@Named
annotation class DatabaseLogger

@Single
@InMemoryLogger
class LoggerInMemoryDataSource : LoggerDataSource

@Single
@DatabaseLogger
class LoggerLocalDataSource(private val logDao: LogDao) : LoggerDataSource

These dependencies would be injected that way:

val logger: LoggerDataSource by inject(named<InMemoryLogger>())

They would also be injected into constructors using the same annotation.

I think the syntax looks better that way but not everyone may think the same. Regardless, I feel like it wouldn't be a bad idea to give the developer the ability to choose between whatever option they prefer to declare a qualifier.

I don't have a lot of experience with KSP but I've managed to implement the feature (it works with either @Named or @Qualifier). I have no idea of the impact on compilation speed, but I'd expect that there is at least some impact because in order to find the qualifier for a definition, we need to resolve each of its annotations until we find one whose declaration is annotated with @Named or @Qualifier.

This could be extended to Scopes as well, I don't personally use them a lot, but I could try to implement the same feature for Scopes.

@arnaudgiuliani
Copy link
Member

Sounds smart improvement to let people define their qualifier annotations 👍

@arnaudgiuliani
Copy link
Member

Other point we could explore from there is if we can use directly the annotation, instead of named(). The idea is to generate named() at the end, but avoid us to write named() but directly use the newly defined annotations

@skyecodes
Copy link
Author

Other point we could explore from there is if we can use directly the annotation, instead of named(). The idea is to generate named() at the end, but avoid us to write named() but directly use the newly defined annotations

I don't really know how that would be implemented, to be fair. As far as I understand KSP can only generate new code, not edit source code, so I don't know how we could make it so that the named() parameter gets automatically replaced.

If I understood your suggestion correctly we could use this syntax for example?

val loggerInject1: @InMemoryLogger LoggerDataSource by inject()
val loggerInject2 by inject<@InMemoryLogger LoggerDataSource>()
val loggerGet1: @InMemoryLogger LoggerDataSource = get()
val loggerGet2 = get<@InMemoryLogger LoggerDataSource>()

After processing (if KSP allowed to edit source code):

val loggerInject1: LoggerDataSource by inject(named<InMemoryLogger>())
val loggerInject2 by inject<LoggerDataSource>(named<InMemoryLogger>())
val loggerGet1: LoggerDataSource = get(named<InMemoryLogger>())
val loggerGet2 = get<LoggerDataSource>(named<InMemoryLogger>())

I don't know how we could do that unless we create specific inject() / get() methods for each annotation type (example: injectInMemoryLogger()), but creating new methods based on the annotation name doesn't seem like the best idea; I also lack experience with KSP so please let me know if you have a better idea.

@arnaudgiuliani arnaudgiuliani deleted the branch InsertKoinIO:2.0.0 October 16, 2024 15:33
@arnaudgiuliani arnaudgiuliani changed the base branch from 1.4.0 to 2.0.0 October 16, 2024 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants