Named/tagged "fallback" approach leads to multiple singletons
Closed this issue · 2 comments
I'm struggling to understand the reasoning or the approach I should be taking when using "tag" due to the fallback design
https://github.com/AliSoftware/Dip/wiki/named-definitions#note-on-fallback
It appears it can lead to flagrant disregard of (.singleton) scopes, and then to very difficult to find bugs. I can easily see how the innocuous use of naming parameters could lead to unwanted clones of singleton objects. Your very example modified slightly suggests this would be the case
class OAuth2Service { //The one to rule them all
init(){}
}
class APIClientImp{
init(url: NSURL, oauth: OAuth2Service) {}
}
container.register(.singleton) { OAuth2Service()}
container.register(tag: "api") { NSURL(string: ...)! }
container.register(tag: "api2") { NSURL(string: ...)! }
container.register { try APIClientImp(url: $0, oauth: $1) as APIClient }
let container = try! container.resolve(tag: "api") as APIClient
let container2 = try! container.resolve(tag: "api2") as APIClient
container1.oauth !== container2.oauth
This would catastrophically create two OAuth2Service() services despite clear instructions against that.
What alternatives are there? I'm concerned this will be debilitating since you need to somehow register and tag primitives.
Fill free to reopen this if you have any further questions @jtwigg