._.

Just switched to kodein and dropped Dagger2 🎉

Can somebody explain why the proguard rule

-keepattributes Signature

is required. It works great without this rule and I can’t find where kodein is using a Signature class

Honestly, I don't remember... Might be a relic of version 2 :p

I’m not too deep into the implementation but I don’t get why

erased

is not the default. Generic types seem to be an edge case. I checked a few large (internal) projects and couldn’t find a single generic type when using Dagger2.

I personally would drop support for the

erased

module in

4.0

and promote it to default for performance reasons

and

kodein.instance()

should by default map to

kodein.Instance(erased())

and a new

kodein.genericInstance()

could inject generic types

@passsy It is a debatable choice, I agree. The rationale is that I want Kodein to be easily understandable at first glance. The problem is that I can't force the user to not use generics when bindings erased. This means that someone using erased by default and writing

bind<List<Person>> with singelton { getContactList() }

will risked being fooled. When using erased, one should always use only the star syntax : ``bind<List<*>> with ...`, but there are no ways to enforce this !

I am curious to hear about everyone who think erased should be default 😉

@apatrida @eygraber

@passsy first a question: what is the problem with using full types as the default, I've never had a case where I needed to use erased types at all in any app with either Injekt or Kodein which covers a few solid years of 100% Kotlin code every day. @salomonbrys looking at my bindings in our biggest app, about 10% of them have generics (not collections, but custom classes with generics) ... and from experience with Jackson data binding and generics, most newbies (like 80%+) make a mistake not using generics when they should and then end up asking redundant Stackoverflow questions because they don't understand the importance and problems of type erasure. I need to understand the problem not having erased as default is causing?

Only performance 😉

ah, this is an Android thing then

The

erased<T>()

function (which is a simple alias to

T::class.java

) is a lot faster than

generic<T>()

which extracts all generic informations.

do you do some checking on the generic parameters?

to see if they fit the bounds?

Fit which bounds ?

do you do some checking of generic parameters to see if the requested parameterized type can be satisfied by the bound type even down to the generics? or just that it is an exact match of parameterized types? or? I don't get what "extracts all generic informations" is doing

Extract a

ParameterizedType

.

the

genericToken<T>()

call

Yep

and that is slow, didn't realize

It creates a generic subclass and uses reflection to extract a ParameterizedType. This is quite show, but it's the only way to get a proper one.

you could add caching inside of the TypeReference code

?

Given a class, you get the

genericSuperclass

and then get the type from there, which you then later return as some wrapped type. anyway to just cache the wrapped type and check for the original class before you do the reflection process. or maybe it has to happen in your inline function instead (it is creating a new class each call?)

just thinking of ways to optimize that code so this isn't an issue.

otherwise: seems like you implemented the safest default and give the ability for optimization using erased for the cases where a runtime environment is resource constrained, sounds like it is already the right best plan.

server-side I don't think Kodein has ever showed up in profiling sessions as a noticeable hot spot

Also, IMHO, perf matters in critical path, and more often than not, injection is NOT a critical path as it does not happen very often in the lifetime of an injected class.