class Configuration:
pass
@inject()
class ExtendedConfiguration(Configuration):
pass
Coming from a well-established DI system like Spring, one would expect di[Configuration] to return an instance of ExtendedConfiguration. In my opinion this should be the case when the parent class(es) don't have an @inject decorator. It's a simple case and kink should support it in the future.
Things get complicated fairly quickly though, for example, by decorating Configuration with @inject. The question now becomes: "Should ExtendedConfiguration override its parent class?". In my opinion there is no clear answer but it should be configurable in the decorator.
We can make things even more complicated by extending ExtendedConfiguration further. Should this new class alias both of its parents? Which candidate should be injected when we ask for Configuration? Again, hard to say, but that's why I'm opening this issue. Hopefully there is some interest in this discussion and we can make kink more robust as a DI system. For inspiration we can look at Spring or .NET.
Finally, if this is deemed too complex to implement, I'd like to know so I can do it in my application instead.
Imagine this example:
Coming from a well-established DI system like Spring, one would expect
di[Configuration]to return an instance ofExtendedConfiguration. In my opinion this should be the case when the parent class(es) don't have an@injectdecorator. It's a simple case and kink should support it in the future.Things get complicated fairly quickly though, for example, by decorating
Configurationwith@inject. The question now becomes: "ShouldExtendedConfigurationoverride its parent class?". In my opinion there is no clear answer but it should be configurable in the decorator.We can make things even more complicated by extending
ExtendedConfigurationfurther. Should this new class alias both of its parents? Which candidate should be injected when we ask forConfiguration? Again, hard to say, but that's why I'm opening this issue. Hopefully there is some interest in this discussion and we can make kink more robust as a DI system. For inspiration we can look at Spring or .NET.Finally, if this is deemed too complex to implement, I'd like to know so I can do it in my application instead.