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.corde...@sympla.com.br>: > > 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 <%2B55%2031%203024%200283> [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/CADuw3E_Y1TCumMvKyPWhxt_CSOBiX4nJU9DmgxhovbVkJJdLdw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
