Hi Pedro, > However, as an application developer, this PSR doesn't help me much as is...
Absolutely true. You are also right to note that this PSR is not directly targeted at end users but rather at frameworks. You should view container interoperability as a multistage rocket. The first stage of the rocket is PSR-11. Out of the box, even if you can't put things into the container, PSR-11 is still useful. Have a look at Zend-Expressive if you want a great example. Zend-expressive is allowing you to use many routers and many containers. The router is instantiating the controller through ContainerInterface `get` method. This way, the router is not dependant on one specific container (consider how this better than in Silex for instance, where Pimple is the only possible container). This is already a great win. The second stage of the rocket is to be able to put things in the container. A best candidate we have found so far to fulfill this task is universal service providers. If you want a taste of what it might look like, head over to https://github.com/container-interop/service-provider/ (this is alpha so be gentle and forgiving :) ). You will notice that PSR-11 is a prerequisite for those service providers. You say: > A possible new PSR that defines how to set/add services shouldn't extend PSR-11 because of this. I beg to disagree. In container-interop/service-provider, containers consuming the ServiceProvider interface MUST return a shared instance for services contained in the service provider. Yes, a container *can* in some cases return new services for some entries. But I'm still capable of writing a service-provider PSR that dictates that consuming containers MUST return shared services for services contained in my service provider. Both statements are not incompatible. ++ David Twitter: @david_negrier Github: @moufmouf Le jeudi 27 octobre 2016 19:04:06 UTC+2, Pedro Cordeiro a écrit : > > To phrase it better: specifying that setting a service is out of scope for > this abstraction and yet having this abstraction's behavior depend on how > the service was set sounds really inconsistent and greatly limits the > possible use cases for this standard. > > 2016-10-27 14:56 GMT-02:00 Pedro Cordeiro <pedro.c...@sympla.com.br > <javascript:>>: > >> > 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). >> > > > > -- > > *Pedro Cordeiro* > Produto > > Phone: +55 31 3024 1115 > > [image: Logo assinatura] > <http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiXwUuwMLrMuwyQMihLilvGuFQlwqGcwaqcxv14TZBo-2Fkx216CWkoFS-2BFrkKrfuwK-2BVQHJQ1z2pKo2dYIxq5cmilGdRu7bAh5za9wh3RLzO4nA-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIEnG1Q-2F2tN-2BOSPuz0Nn8uv2ZSfKxBLUbTLKbmGhzSIZRi0PYxNI8DwJc7HKhR0hHwKI8kmuyZfBkzNrxoCmV0NXGSkn3a3WzIqMEkuwdILSgR-2Fm4Yi08v1XJ0ACOgxAjO-2BND8H30UmwWPAPr6joAP3kKuQ6WcA7R-2FTErDPH0l26ly5T8d00DrbMV7fXYAiuL24XcUrHvHs1-2BIk0UWwDs-2F72MMLfB2NOFl6lJHtovPskkuiwYJajeWEJycLVSCkLape6k6LHU-2BSZcF2Uvp2Asye0iUJTldf0eVlnrql-2BA6I-2F6d00ZAiOxLHEVlUTd1ixtgJipaRe0L1jjobMF41uBNJLCRzafhz8q5oziitdm7z7VLEgrZz2klJhql8ltu8q97TK> > > > <http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiXwUuwMLrMuwyQMihLilvGuFQlwqGcwaqcxv14TZBo-2Fkx216CWkoFS-2BFrkKrfuwK-2BVQHJQ1z2pKo2dYIxq5cmilGdRu7bAh5za9wh3RLzO4nA-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIEnG1Q-2F2tN-2BOSPuz0Nn8uv2ZSfKxBLUbTLKbmGhzSIZRi0PYxNI8DwJc7HKhR0hHwKI8kmuyZfBkzNrxoCmV0NXGSkn3a3WzIqMEkuwdILSgR-2Fm4Yi08v1XJ0ACOgxAjO-2BND8H30UmwWPAPr6joAP3kKuQ6WcA7R-2FTErDPH0l26ly5T8d00DrbMV7fXYAiuL24XcUrHvHs1-2BIk0UWwDs-2F72MMLfB2NOFl6lJHtovPskkug8HnNMYMLjg6qWS45zCOIrm0vptTNigLUcaaUyHWLPOZGe0FSmf9PqyBfjwjFw-2F88h7bt2F1L5K-2FcCWvoYbYXvfmpn1s4vRjzgBFGFfMaV4wNfAKPCaPqR75Md-2Flsd-2F7ry86VRGQ2Sc0YQoNvf1REv>*O > > site com o maior número de eventos à venda do Brasil!* > > <http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiXwUuwMLrMuwyQMihLilvGuFQlwqGcwaqcxv14TZBo-2Fkx216CWkoFS-2BFrkKrfuwK-2BVQHJQ1z2pKo2dYIxq5cmilGdRu7bAh5za9wh3RLzO4nA-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIEnG1Q-2F2tN-2BOSPuz0Nn8uv2ZSfKxBLUbTLKbmGhzSIZRi0PYxNI8DwJc7HKhR0hHwKI8kmuyZfBkzNrxoCmV0NXGSkn3a3WzIqMEkuwdILSgR-2Fm4Yi08v1XJ0ACOgxAjO-2BND8H30UmwWPAPr6joAP3kKuQ6WcA7R-2FTErDPH0l26ly5T8d00DrbMV7fXYAiuL24XcUrHvHs1-2BIk0UWwDs-2F72MMLfB2NOFl6lJHtovPskkuh-2FcAWngEps85gZcv1JSt88f2MW6opGq90KNlySvzdU-2Fye89UtpBfv3fUye6Q18GdWjcQkrSLGREh4GUTjQXGm2TY6JDX6BMrWAmqiU-2BRatDqBDMb7o4f0IPHrMBwqWCmc1qGopJBiN5-2FLRBjhg40Gq> > www.sympla.com.br > <http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiVLI3wuhL5Ti6hw89C0ESCSVJNdh8FfaGqV-2BFmL5HRlzZKExa4qrB0ctNsViB6l8TFdI11l371V56-2Ffz1iwPM-2FaLxM6A0XQGU-2B6JVEDbnNA0Q-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIEnG1Q-2F2tN-2BOSPuz0Nn8uv2ZSfKxBLUbTLKbmGhzSIZRi0PYxNI8DwJc7HKhR0hHwKI8kmuyZfBkzNrxoCmV0NXGSkn3a3WzIqMEkuwdILSgR-2Fm4Yi08v1XJ0ACOgxAjO-2BND8H30UmwWPAPr6joAP3kKuQ6WcA7R-2FTErDPH0l26ly5T8d00DrbMV7fXYAiuL24XcUrHvHs1-2BIk0UWwDs-2F72MMLfB2NOFl6lJHtovPskkuhalNGqZenIN2ujgLDSs5Ohlft6K9qJu5v-2FZ3QUR1aZ9-2FzqGgwzr01AaKq7A-2FhO998bW0GWIpli0JgybJylzgA2ITDrio-2FSPnUvfYn56sgyWGIEtX1JTsSWBKJ7DZK8go8mcVbmwvX2oitsQJ8jGzKm> > -- 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/d49bc29b-dee8-42b3-89ac-2e4b87142aee%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
