Closed harikt closed 7 years ago
This is what happens when we bind a library to an external interface -- the semantics change, even when the interface itself does not. :-/
I say if you want two different service instances, then define two different services.
I would not want the semantics of Aura\Di\Container::get()
to change to that of the intended meaning for the ContainerInterop interface. I get the impression that a lot of the containers that follow ContainerInterop strictly are service locators, not true dependency injection containers.
Some of these containers simply won't let you use more than one service with the same class at all because they will only use the name of the class as the service name. Aura.Di is more advanced than that, and it's a good thing.
The
ContainerInterface
get method looks a bit problematic .Text copied from https://github.com/container-interop/container-interop/blob/master/docs/ContainerInterface.md#11-basics
The Aura.Di get only returns single instance when it is called once / twice .. There is already a discussion regarding the same : https://github.com/container-interop/container-interop/issues/69 According to the discussion https://github.com/container-interop/container-interop/issues/69#issuecomment-251050021 mentions about the containers
can produce different instances.
There is also a discussion https://github.com/container-interop/container-interop/issues/44 where @pmjones is part of.
So what will be the best way to produce new instances for the registered service and a shared instance accordingly?
In Aura.Di we register as
But the fact is regardless of what / how we register the service we only get one instance. Probably we need to make some way so that the behaviors are same for all Di containers in the wild.
Thoughts ?