Hi, Matthew! Thanks for replying :) Larry and I presented a few cases where the framework relies on its components having a shared instance, instead of exclusive ones. Every framework component that fetches services that handles connections, IO sockets, in-memory caches, and others HAVE to be given shared instances. Being fed new (empty) in-memory caches every time is crazy, right? :) If you could address how we can deal with these cases with factory-only containers, maybe it could be clearer to me.
I don't really agree that most services are only fetched once by the framework -- an event dispatcher (that traditionally has an in-memory registry of listeners that must be shared) could be fetched various times by various different components - to register new listeners or to simply dispatch events. It would depend on the framework here. Maybe a microframework tends to fetch less, but a fullstack framework could really differ in that aspect. Like I said before, I would agree that it's an application/configuration issue if all containers were interoperable on a behavior level. If the user had misconfigured a container to act as factory for a specific service, where it should be retrieving shared instances, ok, that's a bug, not this PSR's fault. However, once we decide to allow factory-only containers, we define that there is no way to configure these containers properly for components that need shared instances (such as the ones I mentioned previously). Hence, we have a compatibility issue. Again, choosing the right containers for my use is not a configuration/application issue. PSR-11's goal SHOULD be container interoperability. Which means containers should agree on a minimum behavior to be interoperable. If we need to code to specific implementations, than a standard is not needed at all. I won't dwell any more into this issue, because I feel like I'm bashing the same key over and over again. I feel like I've said all I had to say in that aspect, and I only have the best intentions in mind for this PSR. If you all feel like it's not a big issue, then let's move on. I do feel like it's a big issue, though. Em terça-feira, 8 de novembro de 2016 17:54:08 UTC-2, Matthew Weier O'Phinney escreveu: > > > > On Tue, Nov 8, 2016 at 6:55 AM, Pedro Cordeiro <pedro.c...@sympla.com.br > <javascript:>> 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 > mweiero...@gmail.com <javascript:> > 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 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/d7449811-ea4e-4205-92fc-c48af05e024e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
