AliSoftware/Dip

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