Skip to content
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

Closed
yayaa opened this issue Jun 24, 2019 · 3 comments
Closed

Immutable Graph #505

yayaa opened this issue Jun 24, 2019 · 3 comments
Milestone

Comments

@yayaa
Copy link

yayaa commented Jun 24, 2019

Is your feature request related to a problem? Please describe.
With Koin v2.0 load and unload 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;

  • Dagger, provides 2 alternatives for this case, one to have components depending on other components and the second one is to create subcomponent from another component. In both cases, you could have additional modules only for this extended/sub component.
  • Kodein, provides 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.

@n-belokopytov
Copy link

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.

@arnaudgiuliani
Copy link
Member

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.

@arnaudgiuliani arnaudgiuliani added this to the 2.1.0 milestone Dec 17, 2019
@arnaudgiuliani
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants