Hi all, <@U1ZQ36CJD> great job of benching Kodein ...

# kodein

[salomonbrys]

Hi all,
@spierce7 great job of benching Kodein got me thinking.
Kodein is immune to type erasure thanks to the combination of inline reified and getGenericSuperclass.
Now it appears that using getGenericSuperclass, while ensuring type erasure immunity also badly impacts performance.
So, I'd like to propose an API that is NOT immune to type erasure, and therefore do NOT use getGenericSuperclass.

I see two ways of proposing such an API (in a backward compatible way, of course) :
1/ Add a new set of prefixed extension functions. For example: kodein.instance<A>() would use getGenericSuperclass while kodein.classInstance<A>() would NOT.
2/ Copy the set of extension functions in a different package. This means that kodein.instance<A>() would use getGenericSuperclass if imported with import com.github.salomonbrys.kodein.instance and would NOT if imported with import com.github.salomonbrys.kodein.WITHCLASS.instance.
3/ Add a set of API that takes a KClass to kodein.typed, so that, when you want to be optimized, you can use kodein.typed.instance(A::class)

Option 1 & 3 are more verbose but also more explicit. Also, it does not enable the programmer to use optimized by default, unless using import as.
Option 2 hides the choice of optimization, which is not necessarily a bad thing. Also, it does not enable the programmer to use both optimized and erasure-immune in the same file, unless using import as.

So here is the poll:
- Please react with 1️⃣ if you think option 1 is better (one)
- Please react with 2️⃣ if you think option 2 is better (two)
- Please react with 3️⃣ if you think option 3 is better (three)
- Please react with ✅ if you think those optimized functions should be proposed in the core kodein module (white_check_mark)
- Please react with ❎ if you think those optimized functions should be proposed in a different module such as kodein-class (negative_squared_cross_mark)

Thank you all 😉!