• Adds modules which are just collections of providers that can be registered all at once in an InjectorBuilder
• Adds a define_module! macro which can be used to easily create those modules

Closes #13

• [x] Allow for multiple providers or implementations to be registered for a service/interface.
• [x] Allow each implementation/instance of a service to be requested via some kind of iterator. For instance, allow some type Services<dyn Interface> to be requested as a dependency, and have that return instances of Svc<dyn Interface> for each implementation of Interface that has been registered. This should be easier now that Injector is cloneable.
• [x] Allow services to still be requested via Svc<dyn Interface> or Svc<Foo> without needing to use an iterator. This should cause an error to be returned if there are multiple providers available.

Adds conditional providers which are skipped if their condition is not met. Currently only TypedProviders can be nested in ConditionalProvider. Hopefully when GATs are eventually released WithCondition can also be implemented on Provider.

Resolves #29

Cleans up existing code. This includes breaking changes.

• Reduces number of times RequestInfo is cloned by changing signatures to take &RequestInfo instead of RequestInfo
• Made ServiceFactory<D> be a subtrait of Service since providers need to implement Service anyway
• Fixed Clone implementation for Factory<R> requiring R: Clone (limitation of #[derive(Clone)])
• Added additional example to Factory
• Fixed CI not failing on clippy failures
• Incremented version numbers for runtime_injector and runtime_injector_actix

Adds Factory<R> which allows requests to be performed lazily. Since Factory<R> has no lifetime parameter, it can be stored in a struct and requests can be made to it later during the program's execution.

Changes interface! macro to require dyn Trait = [...] instead of just Trait = [...]. This makes the macro work more similarly to other parts of the library, like define_module! which needs dyn Trait = [...] when defining providers for an interface, and Svc<dyn Trait>/Services<dyn Trait>/etc when requesting an instance of the interface.

Also adds support for trailing commas and multiple interface definitions in the same interface! block.

While this is technically a non-breaking change (trait objects don't currently need an explicit dyn to compile), it adds a bunch of extra warnings to existing code, so this change will wait until 0.4.

Adds support for injecting target-specific arguments to configure how services are created. Also updates the define_module! macro to make it easier to specify those arguments.

Closes #23

Rather than relying on constant(value) to inject an argument to a service, allow services to have custom arguments set for them:

let mut builder = Injector::builder();
builder.provide(Foo::new.singleton());
builder.with_arg::<Foo, i32>();

Added docs for how dependency injection (and an IoC container) can benefit an application. These docs can be expanded later to add additional information.

Closes #17

Allows some services to be injected via Box<I> rather than needing to be provided via Svc<I>. This allows services to own their dependencies without needing to clone them.

Closes #12

Adds a helper library for working with actix-web. Specifically, refactors the repository quite a bit to allow for multi-crate workspace, and adds an Injected<R> type that can inject container requests into actix-web requests.

#[get("/")]
fn index(
    my_service: Injected<Svc<MyService>>, // inject some custom service
    injector: Injected<Injector>, // any request is supported, even non-service requests
    // ...
) -> impl Responder {
    todo!()
}

Closes #19

Hey, I started playing around with this DI container but I'm unable to achieve interior mutability. Could you provide some examples how that could be achieved with both Svc modes (Rc/Arc) and:

• Cell,
• RefCell,
• Mutex,
• RwLock,
• or any other wrapper of any kind?

I've only found the example for constant with the Mutex in one of the docstrings:

builder.provide(constant(Mutex::new(0i32)));

I would like to be able to provide particular component wrapped for example by Mutex and then be able to retrieve this Mutex from the container.

I've created small example with comments what I would like to be able to achieve:

use runtime_injector::*;
use std::cell::{Cell, RefCell};
use std::error::Error;
use std::sync::{Mutex, RwLock};

pub trait Foo: Service {
    fn increase(&mut self);
}

#[derive(Default)]
struct FooImpl(u64);

impl Foo for FooImpl {
    fn increase(&mut self) {
        self.0 += 1;
    }
}

pub trait Bar: Service {
    fn increase(&mut self);
}

struct BarImpl {
    foo: Svc<dyn Foo>,
}

impl BarImpl {
    // Not possible to get Cell/RefCell/Mutex/RwLock
    pub fn new(foo: Svc<dyn Foo>) -> Self {
        Self { foo }
    }
}

impl Bar for BarImpl {
    fn increase(&mut self) {
        self.foo.increase();
    }
}

interface!(
    dyn Foo = [FooImpl],
    dyn Bar = [BarImpl]
);

fn main() -> Result<(), Box<dyn Error>> {
    let mut builder = Injector::builder();

    // No obvious way to allow interior mutability, like auto creation of Cell/RefCell/Mutex/RwLock
    builder.provide(FooImpl::default.singleton().with_interface::<dyn Foo>());
    builder.provide(BarImpl::new.singleton().with_interface::<dyn Bar>());

    // It could be available for example in such way:
    builder.provide(FooImpl::default.wrap_in_mutex().singleton().with_interface::<dyn Foo>());
    // or:
    builder.provide(FooImpl::default.wrap_using(|result| Mutex::new(result)).singleton().with_interface::<dyn Foo>());

    let injector = builder.build();

    // Not able to call these as they require &mut
    injector.get::<Svc<dyn Foo>>()?.increase();
    injector.get::<Svc<dyn Bar>>()?.increase();

    // No Cell/RefCell/Mutex/RwLock availability
    injector.get::<Cell<Svc<dyn Bar>>>()?.increase();
    injector.get::<RefCell<Svc<dyn Bar>>>()?.increase();
    injector.get::<Mutex<Svc<dyn Bar>>>()?.increase();
    injector.get::<RwLock<Svc<dyn Bar>>>()?.increase();

    Ok(())
}

• Relaxed constraints for ServiceFactory
  • Moved Service constraint to the provider implementations
  • Result only constrained by Any rather than Service
• ServiceFactory::invoke now takes &self, meaning it doesn't need to be locked to be used in a thread-safe manner
  • Implemented on Fn rather than FnMut now
  • Neither FallibleServiceFactory nor the Fn (previously FnMut) implementations need &mut self

Add a way for providers to have a scope. For example, one way a scope might be implemented is this:

let scope = injector.scope(); // has Drop impl
let foo: Svc<Foo> = scope.get().unwrap();

Scoped providers don't guarantee the lifetime of the values that they provide. If a scope is dropped, there's no way to know if all references to the services it provided were dropped since they use reference-counted pointers or have been moved to outside of the injector (in the case of owned injection). Instead, scopes only would guarantee that scoped providers provide the same instances from the same scope, and different instances from different scopes.

Suppose a config is reloaded during execution of a program. This would allow services to be reconfigured based on the changes in that config. Currently, it's somewhat possible using factories:

struct FooFactory {
    injector: Injector,
    config: Svc<Mutex<Config>>
}

impl FooFactory {
    pub fn new(injector: Injector, config: Svc<Mutex<Config>>) -> Self {
        FooFactory {
            injector,
            config,
        }
    }

    pub fn get(&self) -> InjectResult<Svc<dyn Foo>> {
        match self.config.lock().unwrap().foo_impl {
            FooImpl::Bar => self.injector.get::<Svc<Bar>>().map(|bar| bar as Svc<dyn Foo>),
            // ...
        }
    }
}

This is a lot of work to reconfigure just a single service based on a config reloaded at runtime. It might be better to instead expose some functions to mutate the provider map in existing Injectors.

Port a slightly simplified version of the enterprise-edition FizzBuzz solution to Rust and provide it as an example. This should at least show a lot of use-cases for dependency injection and provide as a valuable test.