koin-annotations icon indicating copy to clipboard operation
koin-annotations copied to clipboard

Support generating definitions for object declarations

Open ithersta opened this issue 2 years ago • 9 comments

Is your feature request related to a problem? Please describe. I use JetBrains Exposed and I have several tables declared like so:

object Users : LongIdTable() {
    val name: Column<String> = varchar("name", length = 256)
    ...
}

I want to annotate all tables with @Single and then use getAll<Table>():

SchemaUtils.createMissingTablesAndColumns(*getAll<Table>().toTypedArray())

But the generated definitions for objects call a non-existent constructor and the project doesn't compile.

single(qualifier=null) { auth.data.tables.Users() }

Describe the solution you'd like Generate a proper definition for object declaration without calling a constructor.

Describe alternatives you've considered I tried turning object into a class but it's not ideal since the object is used a lot in queries like so:

Users.batchInsert(user.areas) {
    this[Users.name] = user.name
    ...
}

Target Koin project koin-annotations

ithersta avatar Feb 08 '23 10:02 ithersta

object compiles to an internal class without public constructor and one JVM-global INSTANCE field with the instance. It really doesn't sound like a good match for a DI system like Koin.

I don't know exposed that well, but you probably should turn the object back into class, and only reference it using injected instance, even if it may queries a bit more annoying.

Alternatively, try binding a factory where Users is the type and returned data is Users itself - the object.

ninja- avatar Feb 12 '23 01:02 ninja-

yep, not sure to see the real case. Also Ktor is generating content, not sure about compatibility with Koin Annotations here 🤔

arnaudgiuliani avatar May 10 '23 16:05 arnaudgiuliani

Well, my use case is to automatically find all the tables in my code (and canonically they are objects in Exposed) so I don't have to list them manually during schema creation. It's not really about dependency injection, more like plugin discovery, so maybe it's out of scope for Koin.

ithersta avatar May 10 '23 16:05 ithersta

I can submit a PR if you want to

ithersta avatar May 20 '23 11:05 ithersta

A work around is to declare operator fun invoke() = this on the objects. It may not be pretty, but it is a valid work around (koin really should only call the constructor if the definition isn't an object (which is known during KSP), I ran into the same issue with defining a module as an object and the invoke operator function did the trick)

undermark5 avatar Sep 12 '23 13:09 undermark5

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Mar 30 '24 05:03 stale[bot]

This seems like something similar to #107 would work here.

undermark5 avatar Mar 30 '24 15:03 undermark5

yes duplicated

arnaudgiuliani avatar Apr 04 '24 10:04 arnaudgiuliani

Not exactly. Last I checked #107 only impacted module definitions, not dependency definitions. That is that I don't think that #107 in it's current form provides a solution for this issue.

undermark5 avatar Apr 04 '24 13:04 undermark5

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Sep 01 '24 21:09 stale[bot]