nashenas88 / coi Goto Github PK

Currently it's not possible to add a field that's not Arc<...>. This makes sense for fields that are #[inject], but fields that are not #[inject] are also rejected, which should not occur.

The following is rejected, when it should not be:

#[derive(Inject)]
#[provides(Struct with Struct::new())]
struct Struct {
    a: usize,
}

impl Struct {
    fn new() -> Self {
        Self { a: 0 }
    }
}

A regression test for this was added

Is this code in the README.md redundant?

       let mut container = container!{
            trait1 => Impl1,
            trait2 => Impl2.scoped,
            struct => JustAStruct.singleton
        };
        let mut container = ContainerBuilder::new()
            .register("trait1", Impl1Provider)
            .register_as("trait2", Registration::Scoped(Impl2Provider))
            .register_as("struct", Registration::Singleton(JustAStructProvider))
            .build();

I've looked at the test cases and they only contain the the first way to construct the container.

Since the code in the readme might be the first impression of coi, I think this should be adressed.

Currently, tuples and tuple structs cannot be used with #[derive(Inject)] or #[inject]. It should be possible for the #[inject] attribute to get parameters, one of which could be the name to use when injecting. For example:

#[derive(Inject)]
#[provides(dyn Trait1 with Impl1(unnamed))]
struct Impl1(#[inject(unnamed)] Arc<dyn Dep>);

Does coi verify the dependency graph? If so, is this done at compile time, or run time?

It would be nice to have some injected structs that are generic, and the providers would be generic as well.

Example:

#[derive(Inject)]
#[provides(Pool<T> with Pool::new())]
struct Pool<T>(RealPoolType<T>);

impl<T> Pool<T> {
    fn new() -> Self {
      let pool = // construct pool with T
      Self(pool)
    }
}

let container = container! {
    pool => PoolProvider<Tls>
};

let pool = container.resolve::<Pool<Tls>>("pool");