-
-
Notifications
You must be signed in to change notification settings - Fork 728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Immutable Graph #505
Comments
I appreciate the ability to load a module - it makes all the boilerplate that is needed to maintain a hierarchy of modules and subcomponents disappear. It's not "easy" to accidentally load another module, thus I don't believe the concern is well-founded. |
What we can do is make is to reinforce relations between modules to help check them, ensure more secure loading and linking strategies. Make the internal dependency graph immutable seems to me a bit hard to see, as this means that you would clone the graph each time you want to extend it? Dependency resolution is entirely dynamic as we only know what to resolve, only we execute the definition function. If you check the internal BeanRegistry, it keeps definition under Maps. |
New resolution engine from 2.1.0 make all definitions as immutable, and just allow a resolution tree node to mutate. Everything is immutable, except instance values then. |
Is your feature request related to a problem? Please describe.
With Koin v2.0
load
andunload
modules functionalities were introduced to provide a way to have specific instances only when they are needed. Although, the implementation makes the graph itself mutable considering that any period of time some dependencies (with its module) can be added and removed - which creates an inconsistent behavior and prone to error.Describe the solution you'd like
Instead of load/unload modules from Koin itself, create a way to extend given Koin with additional modules.
As examples from alternative solutions;
extends
functionality to pass a kodein instance and additional modules to create a new kodein instance.In both alternative solutions, graphs are immutable. Both the original and the extended ones.
The text was updated successfully, but these errors were encountered: