search

hmlongco / Resolver

Swift Ultralight Dependency Injection / Service Locator framework
MIT License
2.14k stars 187 forks source link

ResolverRegistration - for a dependency resolution use a resolver with which the registration was created #155

Closed paulovets closed 2 years ago

paulovets commented 2 years ago

Hi there

Hope you are doing well and thank you for your effort

I'm submitting a

Use case

I use nested containers to be able to reinitialize some services e.g when log in/out

What is the current behavior

When I create a child container, register some services on it with the container scope and at some moment later clear a cache on it - actually nothing to clear, because the services are in the main resolver's cache

What is the expected behavior?

When a service is registered on a child container with the container scope - it's written in it's cache, not in the main one

majie776 commented 2 years ago

这是来自QQ邮箱的自动回复邮件。   邮件已收到

hmlongco commented 2 years ago

Sorry for the delay here. I've been working on getting my latest DI system, Factory, out the door.

I'm looking at that code and while I agree that it's a discrepancy in your case I'm not sure I'm comfortable making that change.

When you say Resolver.resolve(SomeType.self), Resolver hits the root Resolver (usually main) and that Resolver is responsible for doing the lookup. That instance is passed along to the registration and, in the case of some factory types, into the factory itself in case it needs to resolve something.

If you pass the resolver used in the registration instead, then that resolver will be passed to the factory instead of whatever happens to be the root at the moment. So it if you swapped out the root, say, for a bunch of mocks, then in some cases those mocks would be ignored since sub-dependency resolutions would no longer be starting out from the root of the tree.

It would a fairly significant change in behavior.