Discussion: Should parent classes be automatically aliased?

[Dzeri96]

Imagine this example:

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.

[dkraczkowski]

@Dzeri96 Thank you for your feedback! I appreciate your interest in the library. Your request makes sense but introduces additional configuration and complexity to the interface.

While the implementation itself doesn't necessarily have to be difficult, it does require some decisions and possible interface changes. I'm currently finding it challenging to see how we could configure this while maintaining the simplicity that kink provides for the community. I would like to keep kink's interface as simple and clean as possible.

Happy to hear your thoughts.