On Tue, Nov 8, 2016 at 6:55 AM, Pedro Cordeiro <[email protected] > wrote:
> Hi, Matthew! > > I understand everything you said. About the configuration responsibility, > this PSR's scope and the fact that it's coherent to have non-shared > services in some contexts. I never disagreed with any of that. > > I'll try to be more objective here. > > Given two containers: > > a) "ContainerShared", that implements PSR-11 and ONLY returns shared > instances, no option to configure non-shared services; > b) "ContainerFactory", that implements PSR-11 and ONLY returns non-shared > instances, acts as a factory always. > > Do you agree that: > > 1) These implementations are perfectly fine PSR-11 implementations, as > it's phrased right now? > 2) These implementations are incompatible between themselves for pretty > much every use case, including zend-expressive, that is currently the most > successful case of container interoperability? > 3) The incompatibility between these two containers is not an > application/configuration issue, but plain lack of interoperability between > them? > > If you agree with (1), (2) and (3), the final question that stands is: is > it still OK to have container implementations that are NOT interoperable > implementing an interoperability standard? > I don't agree with your assessment at all. I agree with point 1. I don't agree with either point 2 or point 3. In the majority of use cases I've encountered, the workflow goes something like this: - Application composes a container. - Application does some sort of request routing to determine what service to dispatch - Application pulls that service from the container and dispatches it This means that, regarding point 2, whether or not instances are shared is typically moot. They are pulled from the container generally once, and once only, in any given request. (Yes, there are times when multiple retrieval may happen, particularly in large, event-based applications where multiple listeners may use the same services.) However, this leads to point 3: it's absolutely an application/configuration issue. You need to choose the container that suits your application needs and configure it accordingly. The PSR-11 specification is only around *retrieving* services. It is specifically not detailing how those services are stored within, whether or not the service MUST return the same instance, etc. The point is that if you have a container, can you (a) test if the service is present, and then (b) retrieve it? The *behavior* aspect — if the service is shared or not, and how to configure services in the container — is purposely intended for a future PSR that covers that aspect. For a consumer, they can typehint on ContainerInterface and exercise its API. They retrieve the service, and do something with it. Whether or not that service is shared or the correct instance expected will be entirely up to the container implementation they choose, and how they configure services in that container. So I disagree with your third point as well. <snip> If *YOU*, zend-expressive developer, were to develop a truly agnostic > container consumption implementation based on PSR-11, you'd have to > document something to the effect of: "while zend-expressive is compatible > with PSR-11 containers in general, it's not meant to be used with > factory-only containers. Choose accordingly.". THAT is what strikes me as > something weird to have. > Honestly, Expressive *does not care*. At the application skeleton level, we're not working with shared instances; we're working with a router, an error handler, and whatever middleware we pull from the container. The question of *shared* services comes up for the *application developer*, which is why Expressive *provides a choice of containers*: to allow the application developer to choose the container implementation that suits their project. As long as that container is compatible with the PSR, it's compatible with Expressive, plain and simple, because all we do is exercise its API. -- Matthew Weier O'Phinney [email protected] https://mwop.net/ -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myUXV%3DBOQ%2BU_5Qf7EXhBdk87%3DXxj%2BKprS3H-wamLFgoUoA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
