On Mon, Oct 3, 2016 at 12:54 PM, Pedro Cordeiro <pedronar...@gmail.com> wrote: > Thanks. I think I missed that. > > Anyway, how do I prepare my application to have interoperable containers, > since they don't agree on how to add new services? I will have to write > adapters for each specific implementation... doesn't that defeat the purpose > of the PSR? Shouldn't "adding services" be in-scope, rather than 'let some > implementations rely on autowiring, others have specific methods for > registering'...?
Adding services is usually done at the application level, at which point you've chosen an implementation. The part where it gets interesting is when writing a package that may provide services, and thus potentially configuration or factories for use with a container. That aspect is also being discussed by container-interop, under the projects definition-interop and service-providers (look for those repos under the container-interop organization on github), with the latter looking like the likely approach. Once an approach is vetted, the container-interop group will bring that proposal to FIG as well. The reason the idea of "adding services" is being considered separately is because there's a ton of approaches, and not a lot of commonalities between them. Some containers, like Disco and php-di, are almost entirely reflection and/or annotation driven, meaning they're highly automated. Others, like Pimple and zend-servicemanager, rely on factories in order to generate services. Some, such as Pimple and zend-servicemanager, provide the abiliity to "extend" a service (essentially decorating any existing factories in order to add pre-conditions or perform further initialization tasks once an instance is obtained). Still others provide fallback mechanisms (abstract factories in zend-servicemanager). Determining what the minimum set of features to support is proving to be quite difficult! In the meantime, PSR-11 is already useful. Since you can define the container during bootstrapping of your application, if your application supports PSR-11, you pass it the container, and all it should be doing is calling one or the other of has or get, typically in order to pull something such as a controller or middleware, and all related dependencies. By the way, if you're interested in one approach to the "adding services to disparate container implementations" problem, we tackled it in the zend-expressive-skeleton. We're also evaluating an approach we call "config providers" that is not dissimilar to the way service-providers works, which should allow us to help vet that approach for viability. > Was this discussed? Anyone have a link for the discussion? Search tool here > in googlegroups didn't help me much. > > Thanks again and sorry if I'm missing something. > > Em segunda-feira, 3 de outubro de 2016 14:39:49 UTC-3, Stefano Torresi > escreveu: >> >> Check the meta doc: >> >> https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#3-scope >> >> Il giorno lun 3 ott 2016 alle ore 19:34 Pedro Cordeiro >> <pedro...@gmail.com> ha scritto: >>> >>> I tried searching but couldn't find the reason PSR-11 doesn't have a >>> `register`, `add` or similar method to register a new service in the >>> container. >>> >>> I'm not sure if I misunderstood something, but it looks like I'll still >>> have to create a new contract wrapper around PSR-11 to define how to >>> register new services to the container, and then I'll have to make a bridge >>> for each provider, since they won't agree on how to add new services. >>> Wouldn't it defeat the purpose of this PSR, which is interoperability? >>> >>> -- >>> 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+u...@googlegroups.com. >>> To post to this group, send email to php...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/php-fig/1877a319-8b9e-4150-8048-97e6b43750ce%40googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. > > -- > 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/47bcf0c9-16e2-46f7-bf41-c728e02adf45%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Matthew Weier O'Phinney mweierophin...@gmail.com 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/CAJp_myVGLfhbjiTJu_djDej4ca%2B15JxpP3g4QOoHt-Eqnv5L5w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
