Please let us know what do you think about all of ...

# kodein

[romainbsl]

Please let us know what do you think about all of this!

[eygraber]

Deprecating type binding would be a big pain for me. I have projects with hundreds, if not thousands of bindings. We also use scopes quite heavily.

[romainbsl]

Thank you for your feedback, this is why we didn't deprecate it right away. it is not easy to automate such migration. This is certainly why we won't deprecate anytime soon.
We evolve to help new beginners jumping in quickly with a simpler API, made the docs upon it to favorite this new syntax.
Also, direct binding deprecation is not an issue for you ?

[eygraber]

I don't think I use direct binding at all.

[romainbsl]

Ok. and finally, do you use set bindings ?

[eygraber]

I think we used it once a while ago. Not sure if we still are.

[romainbsl]

Thank you for your feedback. If in any case we decide to deprecate type bindings, we will ensure to provide a smooth migration. In that case we might ask you some help on testing the process. However, it's not a top priority ATM.

[aerialist]

Hi @romainbsl,

Seems, that I can't use new syntax in such cases?

[aerialist]

Is it expected?
Or may be there is a mistake in my code/Kodein API...

[romainbsl]

This is certainly the main drawback from that new API, that is why we didn't deprecate the "old" one.
The new API is built to handle simple use cases.

If your set binding and your singleton binding target the same type you can write the following code:

bindSet<IPerson>()

val singleton : Singleton<Any, IPerson> = singleton { Person("Salomon") }
inSet<IPerson> { singleton }
bind<IPerson> { singleton }

Note that I've explicited the type of singleton property

But if your bindings are on different types, you may need to cast one of them:

bindSet<IPerson>()

val singleton : Singleton<Any, IPerson> = singleton { Person("Salomon") }
inSet<IPerson> { singleton }
bind<Person> { singleton as Singleton<Any, Person> }

or stick to the old API.

[eygraber]

I've started switching to bindProvider on a smaller side project to see what it would look like, and the main downside I'm seeing is that it removes the ability to quickly see what type is being bound:

bind<Fragment>() with provider { context }

VS

bindProvider { context }

[eygraber]

I know I can do:

bindProvider<Fragment> { context }

but that cause my linter to warn me that the type could be removed (and in some projects it's configured as an error).

As long as the original style of declaring bindings never gets deprecated that will be fine, but if it does it could cause problems

[romainbsl]

in fact:

bindProvider { context }

is the equivalent to:

bind() from provider { context }

[romainbsl]

and

bindProvider<Fragment> { context }

is the equivalent to:

bind<Fragment>() with provider { context }

[romainbsl]

my guess is that if you use bind() from ... your linter will raise the same warning ?

[eygraber]

Yup

[eygraber]

bind<Fragment>() from provider { context } would cause the same issue with the linter