This PR adds auto-injection feature.

What is auto-injection

Auto-injection is a feature that let's user to get all dependencies (properties) injected by container automatically without calling resolve for each dependency.

Why we need this

• It's a more convenient way to define circular dependencies
• It will enable automatic injection of dependencies for objects created by storyboards or nibs (as I currently imagine possible implementation of that feature) what I think is a very important feature to adopt Dip in real life projects.

How it works

This implementation provides not completely automatic resolution which seems to be impossible to implement in Swift without using ObjC runtime. So to inject dependencies user needs:

• wrap properties with special wrappers to indicate that they should be injected by container
• obtain an instance of object to inject to (either create it manually or resolve with container)
• call resolveDependencies method of container and pass it this instance

resolveDependencies method uses reflection to inspect types of properties. To work around different issues, like initial nil values of properties, weak references and others we use simple wrapper classes: Injected<T> and InjectedWeak<T>. Using Mirror we iterate over properties and pick up those of type Injected or InjectedWeak (actually dummy internal protocols). Then we use resolve and assign resolved instance to values wrapped by those properties. The fact that Injected and InjectedWeak are classes makes it possible to change wrapped value not only in the mirror, but also in reflected object cause values of mirror children are copied by reference as any class in Swift (though Apple does not document this behavior of Mirror with all the possible consequences).

To be able to resolve this wrapped values for each definition registered with nil tag and block-factory that does not accept runtime arguments we register two additional definitions for Any and AnyObject type (for strong and weak properties correspondingly) associated with special tags. Those tags are just string descriptions of type being registered wrapped in Injected or InjectedWeak. Using such tags makes it possible to distinguish those accessory definitions, cause they all resolve Any or AnyObject types. User will likely not use such tags so there should be no collisions.

Drawbacks

• Using wrappers requires some boilerplate code. The same can be done using resolveDependencies method of DefinitionOf. But using auto-injection registration syntax looks much cleaner. Also I think that Injected and InjectedWeak wrappers serve as a developer's documentation to indicate that those properties will be injected at runtime, so developer does not need to go to the point where all registration is performed. Other frameworks like Typhoon also use similar approach.
• Apple does not document Mirror enough to be sure that required behavior (referencing to child values instead of coping) will not change in future. And actually they already changed reflection API (but not the behavior I believe) between Swift 1.2 and Swift 2.0. But this behavior looks logical and reflection is a language feature, not an OS, so we will be able to adapt (or disable) this feature on demand in later Swift releases.

Example

protocol Server {
  weak var client: Client? {get}
}

protocol Client: class {
  var server: Server? {get}
}

class ServerImp: Server {

  private var _client = InjectedWeak<Client>()

  weak var client: Client? {
    return _client.value
  }
}

class ClientImp: Client {

  private var _server = Injected<Server>()

  var server: Server? {
    return _server.value
  }
}

container.register(.ObjectGraph) { ServerImp() as Server }
container.register(.ObjectGraph) { ClientImp() as Client }

let client = container.resolve() as Client

Checked on Xcode 8 beta 4

• [x] Resolving an instance that has weak properties that are not NSObject subclasses causes a crash. https://bugs.swift.org/browse/SR-2144 Workaround: make your weak properties subclasses of NSObject or do not use weak property attribute.
• [x] Resolving an instance that has IUO properties causes a crash. https://bugs.swift.org/browse/SR-2282 Workaround: use optional properties instead of IUO properties in instances resolved by container.
• [ ] Container is not able to use factories registered with IUO runtime arguments. https://bugs.swift.org/browse/SR-2143 Workaround: do not use IUO as argument type when registering and resolving components
• [ ] Swift compiler may generate warnings when using auto-injection (#139) https://bugs.swift.org/browse/SR-2921
• [ ] Swift does not correctly distinguishes between functions accepting single tuple parameter and functions accepting several parameters of tuple elements types, leading to wrong register method calls (see #147 for details). Should be fixed for Swift 4 with SE-0110

This is mostly about the Singleton scope. In many cases, the "create and preserve after first resolve was made" approach can cause various issues, especially if some of these singletons would use events/signals for communication. To provide more flexibility, it would be great to provide a way for singletons to be created and preserved right away and not waiting for first resolve reference. This could be configured per singleton or as a general Dip property.

Most solid IoC containers provide some form of notification after the object that has some dependencies, has the dependencies resolved.

If I set up my dependencies like so:

container = DependencyContainer { container in
  container.register(.Singleton) { LoginService() }
  container.register(.Singleton) { LoginModel() } .resolveDependencies { container, entity in
     entity.loginService = try! container.resolve() as LoginService
  }
}

I need a way to determine within Login Model when loginService is resolved in, because I might need to instantly operate on it for some reason. I cannot do this in initializer, because loginService isn't injected yet. In theory, I could call a method within the resolveDependencies block, but that doesn't feel like an elegant solution. Does Dip provide/could provide something like this?

Given the Swift API design guidelines, I would like to propose renaming a couple of things in Dip.

DependencyContainer(configBlock:) should be DependencyContainer(configuration:) or DependencyContainer(configurationBlock:). The old initializer could be transitioned to a convenience init that delegates to the new one, and marked as deprecated. (Avoid abbreviations.)

resolve(withArguments:) should become either resolve(arguments arguments:) or resolveWithArguments(_:). The old function should be deprecated and delegate to the new one. (When the first argument forms part of a prepositional phrase, give it an argument label.)

Hello, and thanks for Dip, I've been using it for quite a while and I love it so far.

Today I updated my project to Swift 4 and I found out that some container.register { ... } calls cannot be resolved by the compiler.

container.register { TestClass($0) } // Works fine
container.register { TestClass() } // Nope

The error shown is Ambiguous use of 'register(_:type:tag:factory:)'. I guess because of this change, when the register function is used and no argument is ever used inside the closure, the compiler won't be able to choose between all the 0, 1, 2, 3... args register functions in RuntimeArguments.swift.

As far as I know you still haven't updated the library to work with Swift 4, but I just wanted to report this so it's a known issue for future versions.

Hey, Dip is amazing, and I think its the best DI framework there for swift.

I found that one can register closures types in Dip, naturally I was wondering whether something like this is possible.

struct AType {
    let service: String
    let runtime: Int
}

struct BType {
    let aCreator: (Int) -> AType
    let service: String
}

Suppose I do this

let container = DependencyContainer() { c in
    c.register() {
        "Hello" // This resolves to x as its only string registered
    }
    c.register() {
        AType(service: $0, runtime: $1) // as we don't have runtime Int registered we can resolve it as runtime argument
    }
    c.register() {
        BType(aCreator: $0, service: $1) // This fails as $0 is a closure type which is not registered
    }
}

Can we make closures that return a registered type to auto resolve as closures taking runtime arguments?

I mean

(Int) -> AType

should auto resolve to

 { (a: Int) in try! c.resolve(argument: a) as AType  }

That is if we don't find a closure type registered in container, we check return type of closure, and resolve with arguments for inputs of the closure.

I haven't dived into Mirror yet, so if you think this is possible, I will look into it and give a pull request, or atleast write a extension for personal use. :)

This PR adds support for circular dependencies. That feature and using resolve inside factory block requires recursion, but lock around resolve method causes deadlock. I removed locking completely and propose to managed thread safety on client side.

Hi,

I want to share the same instance of a view model between 2 view controllers. But I don't know how to inject it in them without call resolve() function that "reinit" my view model object instance according to this

Here, part of my Dip container:

self.register(.singleton) { try Repository(graphQL: self.resolve(), fileStorage: self.resolve()) as RepositoryProtocol }
self.register(.shared, tag: "SharedVM") { try SharedViewModel(repository: self.resolve()) as SharedViewModelProtocol }
self.register(storyboardType: AViewController.self, tag: "A")
    .resolvingProperties { container, vc in
        vc.viewModel = try container.resolve(tag: "SharedVM") as SharedViewModelProtocol
    }
self.register(storyboardType: BViewController.self, tag: "B")
    .resolvingProperties { container, vc in
        vc.viewModel = try container.resolve(tag: "SharedVM") as SharedViewModelProtocol
    }

When I load my AViewController, Dip logs:

Trying to resolve AViewController with UI container at index 0
Optional(Context(key: type: AViewController, arguments: (), tag: String("A"), injectedInType: nil, injectedInProperty: nil logErrors: true))
Optional(Context(key: type: SharedViewModel, arguments: (), tag: String("SharedVM"), injectedInType: AViewController, injectedInProperty: nil logErrors: true))
Reusing previously resolved instance Repository
Resolved type SharedViewModelProtocol with SharedViewModel
Resolved type AViewController with <AViewController: 0x157dbcae0>
Resolved AViewController

Then when I push my BViewController from AViewController, Dip logs:

Trying to resolve BViewController with UI container at index 0
Optional(Context(key: type: BViewController, arguments: (), tag: String("B"), injectedInType: nil, injectedInProperty: nil logErrors: true))
Optional(Context(key: type: SharedViewModel, arguments: (), tag: String("SharedVM"), injectedInType: BViewController, injectedInProperty: nil logErrors: true))
Reusing previously resolved instance Repository
Resolved type SharedViewModelProtocol with SharedViewModel // here, I want Reusing previously resolved instance SharedViewModel
Resolved type BViewController with <BViewController: 0x157e58a60>
Resolved BViewController

I don't want to update the view model scope to .singleton because it is not: just a "shared" object for a determinated time

Thanks for helping me

I've think I've encountered somewhat unusual bug/design consequence in Dip:

code

class BaseModel: Resolvable {
    var baseService: BaseService!

    func didResolveDependencies() {
    }
}

class ChatModel : BaseModel {    
    var chatService: ChatServiceProtocol!
}

container:

container = DependencyContainer { container in
    let baseService = BaseService()
    container.register(.Singleton) { baseService as BaseService }

    let chatService = ChatService()
    container.register(.Singleton) { chatService as ChatServiceProtocol }

    let baseModel = BaseModel()
    container.register(.Singleton) { baseModel }.resolveDependencies { container, entity in
        entity.baseService = try! container.resolve() as BaseService
    }

    let chatModel = ChatModel()
    container.register(.Singleton) { chatModel }.resolveDependencies { container, entity in
        entity.chatService = try! container.resolve() as ChatServiceProtocol
    }
}

When I initialize ChatModel somewhere, its baseService is not injected, even though it inherits from BaseModel.

let chatModel:ChatModel = ChatModel()
chatModel.chatService // ok
chatModel.baseService // nil

So it would seem that if objects inherit from other objects, then the properties from inherited object aren't resolved properly, because container doesn't trigger it's process in this case. My goal, was, obviously, to have a ChatModel, that would have both baseService and chatService injected, but I wanted to keep baseService in BaseModel. Did I do something wrong? Is it a bug?

I do realize, that I could initialize chatModel like so:

let chatModel = ChatModel()
container.register(.Singleton) { chatModel }.resolveDependencies { container, entity in
    entity.baseService = try! container.resolve() as BaseService
    entity.chatService = try! container.resolve() as ChatServiceProtocol
}

But that's (overall) not the point of having inheritance in the first place.

Is it possible to use singleton to resolve different interfaces

class ServiceImp {}
extension ServiceImp : SomeService {}
extension ServiceImp : AnotherService {}

let container = ...
container.register(.Singleton) { ServiceImp() as SomeService }
container.register(.Singleton) { ServiceImp() as AnotherService }

Probably we could use next:

let service = ServiceImp()
container.register(.Singleton) { service as SomeService }
container.register(.Singleton) { service as AnotherService }

But does it makes sense?

Bumps tzinfo from 1.2.5 to 1.2.10.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps cocoapods-downloader from 1.2.2 to 1.6.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I find out that optionals definitions lookup was made by combination of filter + isEmpty. The problem with that approach is that it's iterate definitions until the end even when the target elements stored at the begin. This behavior can be optimized using the contains operator.

We're seeing a crash in DIP when creating the initial view controller which through it's references winds up trying to resolve a type which results in a crash. This type can be described as such (using made-up names to simplify):

struct Configuration {}

protocol Foo {}

open class SuperClass: Foo {
   var configsByUser: [String: Configuration] = []
}

class SubClass: SuperClass {}

We register SubClass into the dependency container using the type Foo. When we resolve, there seems to be a crash at https://github.com/AliSoftware/Dip/blob/0193aa6bf6151f7ecd88ff26dba6c0525c3eabd6/Sources/AutoInjection.swift#L48

In this specific case it seems to be trying to deal with the property configsByUser above. In the debugger I am able to see the following:

(lldb) po type(of: child.value)
Swift.Dictionary<Swift.String, Configuration>

It seems that the data in the Mirror is neither AutoInjectedPropertyBox nor ImplicitlyUnwrappedOptional. Accessing child.value at all seems to crash as the debugger cannot do anything with it beyond querying the type as far as I can tell. I saw https://bugs.swift.org/browse/SR-2282 that you filed but that doesn't seem to be the same issue.

I'm unsure if this shows a problem with how things are registered or what but I wasn't sure how to chase this further. Any input would be greatly appreciated as this error happens very frequently in the simulator which is destroying our automated testing. We do not think we've seen this at all on an actual device so that could be another data point.

Hi,

enable thread sanitiser in Xcode.

I used the sample app provided and added this code. in application didFinishLaunchingWithOptions after the configure function.

            DispatchQueue.global(qos: .userInteractive).async {
                _ = try! self.container.resolve() as PersonProviderAPI
            }

i am getting the error below

(lldb) thread info -s
thread #1: tid = 0xb5feba, 0x000000010846d210 libclang_rt.tsan_iossim_dynamic.dylib`__tsan_on_report, queue = 'com.apple.main-thread', stop reason = Data race detected

{
  "all_addresses_are_same" : true,
  "description" : "Data race",
  "instrumentation_class" : "ThreadSanitizer",
  "is_swift_access_race" : false,
  "issue_type" : "data-race",
  "location_description" : "Location is a 144-byte heap object at 0x7b24000196b0",
  "locs" : [
    {
      "address" : 0,
      "file_descriptor" : 0,
      "index" : 0,
      "object_type" : "",
      "size" : 144,
      "start" : 135394549143216,
      "suppressable" : 0,
      "thread_id" : 1,
      "trace" : [
        4433745643,
        4518380009,
        4432193247,
        4432193580,
        4480071751,
        4547030401
      ],
      "type" : "heap"
    }
  ],
  "memory_address" : 135394549143240,
  "mops" : [
    {
      "address" : 135394549143240,
      "index" : 0,
      "is_atomic" : false,
      "is_write" : true,
      "size" : 8,
      "thread_id" : 1,
      "trace" : [
        4455414645,
        4455417239,
        4455399549,
        4455413244,
        4455496011,
        4455490104,
        4455489180,
        4455488196,
        4432186403,
        4432192140,
        4480034918,
        4547030401
      ]
    },
    {
      "address" : 135394549143240,
      "index" : 1,
      "is_atomic" : false,
      "is_write" : false,
      "size" : 8,
      "thread_id" : 3,
      "trace" : [
        4455495051,
        4455490104,
        4455489180,
        4455488196,
        4432190235,
        4432190546,
        4432190881,
        4433864684,
        4546520124
      ]
    }
  ],
  "mutexes" : [
    {
      "address" : 135360189314752,
      "destroyed" : 0,
      "index" : 0,
      "mutex_id" : 1138,
      "trace" : [
        4433615524,
        4456469052,
        4455387904,
        4455395834,
        4455395015,
        4432193247,
        4432193580,
        4480071751,
        4547030401
      ]
    }
  ],
  "report_count" : 0,
  "sleep_trace" : [

  ],
  "stacks" : [

  ],
  "stop_description" : "Data race detected",
  "summary" : "Data race in closure #1 () throws -> A in Dip.DependencyContainer.inContext<A>(key: Dip.DefinitionKey, injectedInType: Swift.Optional<Any.Type>, injectedInProperty: Swift.Optional<Swift.String>, inCollaboration: Swift.Bool, container: Swift.Optional<Dip.DependencyContainer>, logErrors: Swift.Optional<Swift.Bool>, block: () throws -> A) throws -> A at 0x7b24000196b0",
  "tag" : 0,
  "threads" : [
    {
      "index" : 0,
      "name" : "",
      "parent_thread_id" : 1,
      "running" : 1,
      "thread_id" : 1,
      "thread_os_id" : 11927226,
      "trace" : [

      ]
    },
    {
      "index" : 1,
      "name" : "",
      "parent_thread_id" : 0,
      "running" : 1,
      "thread_id" : 3,
      "thread_os_id" : 11927348,
      "trace" : [

      ]
    }
  ],
  "unique_tids" : [

  ]
}


file:///Users/or84489/ws/Dip/Sources/Dip.swift: runtime: Threading Issues: Data race in closure #1 () throws -> A in Dip.DependencyContainer.inContext<A>(key: Dip.DefinitionKey, injectedInType: Swift.Optional<Any.Type>, injectedInProperty: Swift.Optional<Swift.String>, inCollaboration: Swift.Bool, container: Swift.Optional<Dip.DependencyContainer>, logErrors: Swift.Optional<Swift.Bool>, block: () throws -> A) throws -> A at 0x7b24000196b0

notice: Threading Issues: Location is a 144-byte heap object at 0x7b24000196b0

Write of size 8 by thread 1
#0	0x0000000109903b75 in closure #1 in DependencyContainer.inContext<A>(key:injectedInType:injectedInProperty:inCollaboration:container:logErrors:block:) at /Users/or84489/ws/Dip/Sources/Dip.swift:233
#1	0x0000000109904597 in partial apply for closure #1 in DependencyContainer.inContext<A>(key:injectedInType:injectedInProperty:inCollaboration:container:logErrors:block:) ()
#2	0x000000010990007d in DependencyContainer.threadSafe<A>(_:) at /Users/or84489/ws/Dip/Sources/Dip.swift:109
#3	0x00000001099035fc in DependencyContainer.inContext<A>(key:injectedInType:injectedInProperty:inCollaboration:container:logErrors:block:) at /Users/or84489/ws/Dip/Sources/Dip.swift:208
#4	0x000000010991794b in DependencyContainer._resolve(type:tag:builder:) at /Users/or84489/ws/Dip/Sources/Resolve.swift:141
#5	0x0000000109916238 in DependencyContainer.resolve(_:tag:builder:) at /Users/or84489/ws/Dip/Sources/Resolve.swift:123
#6	0x0000000109915e9c in DependencyContainer._resolve<A>(tag:builder:) at /Users/or84489/ws/Dip/Sources/Resolve.swift:131
#7	0x0000000109915ac4 in DependencyContainer.resolve<A>(tag:) at /Users/or84489/ws/Dip/Sources/Resolve.swift:50
#8	0x00000001082dcc23 in AppDelegate.application(_:didFinishLaunchingWithOptions:) at /Users/or84489/ws/Dip/SampleApp/DipSampleApp/AppDelegate.swift:31
#9	0x00000001082de28c in @objc AppDelegate.application(_:didFinishLaunchingWithOptions:) ()
#10	0x000000010b07e866 in -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] ()
#11	0x000000010f062d81 in start ()
Read of size 8 by thread 3
#0	0x000000010991758b in DependencyContainer._resolve(type:tag:builder:) at /Users/or84489/ws/Dip/Sources/Resolve.swift:141
#1	0x0000000109916238 in DependencyContainer.resolve(_:tag:builder:) at /Users/or84489/ws/Dip/Sources/Resolve.swift:123
#2	0x0000000109915e9c in DependencyContainer._resolve<A>(tag:builder:) at /Users/or84489/ws/Dip/Sources/Resolve.swift:131
#3	0x0000000109915ac4 in DependencyContainer.resolve<A>(tag:) at /Users/or84489/ws/Dip/Sources/Resolve.swift:50
#4	0x00000001082ddb1b in closure #1 in AppDelegate.application(_:didFinishLaunchingWithOptions:) at /Users/or84489/ws/Dip/SampleApp/DipSampleApp/AppDelegate.swift:28
#5	0x00000001082ddc52 in partial apply for closure #1 in AppDelegate.application(_:didFinishLaunchingWithOptions:) ()
#6	0x00000001082ddda1 in thunk for @escaping @callee_guaranteed () -> () ()
#7	0x00000001084767ec in __tsan::invoke_and_release_block(void*) ()
#8	0x000000010efe643c in _dispatch_client_callout ()
Heap block allocated by thread 1
#0	0x00000001084596eb in wrap_malloc ()
#1	0x000000010d5101e9 in swift_slowAlloc ()
#2	0x00000001082de6df in AppDelegate.init() at /Users/or84489/ws/Dip/SampleApp/DipSampleApp/AppDelegate.swift:17
#3	0x00000001082de82c in @objc AppDelegate.init() ()
#4	0x000000010b087847 in _UIApplicationMainPreparations ()
#5	0x000000010f062d81 in start ()
Mutex M1138 created
#0	0x0000000108439aa4 in wrap_pthread_mutex_init ()
#1	0x0000000109a0523c in -[NSRecursiveLock init] ()
#2	0x00000001098fd300 in NSRecursiveLock.__allocating_init() ()
#3	0x00000001098ff1fa in DependencyContainer.init(autoInjectProperties:configBlock:) at /Users/or84489/ws/Dip/Sources/Dip.swift:46
#4	0x00000001098feec7 in DependencyContainer.__allocating_init(autoInjectProperties:configBlock:) ()
#5	0x00000001082de6df in AppDelegate.init() at /Users/or84489/ws/Dip/SampleApp/DipSampleApp/AppDelegate.swift:17
#6	0x00000001082de82c in @objc AppDelegate.init() ()
#7	0x000000010b087847 in _UIApplicationMainPreparations ()
#8	0x000000010f062d81 in start ()

please advise