> As you noted in your post, if the user configured its container so that a new dispatcher is injected in each service, this is configuration issue, not an issue with the standard. The user is simply misusing its container.
I understand where you are coming from, and it makes sense from a framework's developer point of view. This is the same conversation we had a while ago, about the scope of this PSR. However, as an application developer, this PSR doesn't help me much as is, because: a) I still need adapters for each specific implementation to add services to the container; b) even though adding services to the container is out of scope for this PSR, I still need to know how to add a service in order to figure out what a specific implementation of `get` will yield (a new instance or a shared instance). So, as an application developer, the fact that this PSR doesn't enforce either way makes even retrieving services (which is the scope of this PSR) unusable without having to adapt my application to specific implementations. Now, to reiterate, I understand this was proposed under FIG 2.0 and that its goal is to help interoperability between the frameworks themselves, not to allow for agnostic implementations on enduser's applications. I'm just pointing out that if setting a service is unknown AND getting a service doesn't enforce shared objects/new instances, I can't truly know in my application how it's going to behave. My main complaint is: *I can end up with a class that depends on a PSR-11 container (a contract/abstraction) but is incompatible with some implementations of PSR11*, and it struck me as something weird to have. This basically excludes the possibility of depending on PSR-11 in my applications. A possible new PSR that defines how to set/add services shouldn't extend PSR-11 because of this. It'd need to redefine if `get` should return a shared/new instance DEPENDING on how the service was set. Currently, I can have a 100% PSR-11 compliant container that either: a) returns new instances each time `get` is hit; b) instantiates on the first hit, returns a shared instance always; c) returns either a new instance each time or a shared instance each time, depending on the "set"/"add" implementation (which is out of scope here). -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADuw3E9Vs-EfS7pMYNeUw5JJRjCv7FUvr6%2BVpBLbdL8WUy%2B-7w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
