Hi Larry, Hi Pedro,
Wooh! That's a lot of comments. Thanks to both of you.
There are really many different issues that need to be addressed in those
review (especially in Larry's posts). I'll not respond directly in this
thread (otherwise it will be hard to follow each issue individually.
Instead, in the coming days, I'll open new threads to address each
individual issue raised (starting with the MUST vs SHOULD debate :) )
This way, we can keep the PSR-11 review readable and understandable.
Thanks,
David.
Le lundi 31 octobre 2016 12:57:05 UTC+1, Pedro Cordeiro a écrit :
>
> Hi, David. Thank you for your response.
>
> Let me address some points.
>
> > Out of the box, even if you can't put things into the container, PSR-11
> is still useful.
>
> I still have a lot of issues trying to think of use cases where I don't
> need to know if the objects I'm retrieving are shared instances or not.
> Since I can't know if the objects are shared, I have to assume they're not.
> Doesn't matter if I'm an application or a framework developer. I can't
> think of how a framework could reliably implement something that consumes a
> service from a PSR-11 container without having this information. I agree
> with Larry 100% here.
>
> $obj = $container->get("something");
> $obj->setThing("myValue");
> $obj2 = $container->get("something");
> var_dump($obj2->getThing());
>
> This snippet here has unknown behavior, not because I don't know the
> properties of the service (which is completely out of scope), but because I
> don't know the behavior of the "get" method (which is completely in-scope).
>
> I understand we don't want to hinder adoption of PSR-11 by being too
> restrictive (and thus locking some implementations out) and I don't have a
> solution to this problem. However, I still believe this is something to be
> addressed.
>
> While writing a framework (as a set of reusable components), I wouldn't
> invoke any containers directly, I'd just rely on having something elsewhere
> injecting my components' dependencies. While writing my application (or a
> bootstrapper/kernel for the framework, which acts as a bridge between the
> framework and the application) is when the container is most useful - and I
> 100% need to know how it behaves there! As an example, Symfony provides a
> kernel can be thought as part of the application domain, not the framework
> domain. It's the base of the "skeleton application" that wires everything
> together. The other components have no knowledge of a container. The
> application is doing all the wiring/retrieving of services - and thus needs
> to know how the wiring behaves (or, at the very minimum, how fetching a
> service from a container behaves).
>
> > * The allowance for additional parameters on get() is worrisome. That
> > implies ANY use of a second or further parameter sets me up for an
> > incompatibility, but implementations are free to add those
> > implementation-specific hooks that I can couple to. I would much prefer
> > to omit that allowance entirely. (Technically optional parameters
> > cannot be prevented, but we shouldn't encourage it.)
>
> Two different implementations of PSR-11 should be compatible between
> themselves and switching between them shouldn't break any implementations
> that depend on a generic PSR-11 container. If anything, I'd specify that
> there MUST NOT be any additional parameters in that call. I'm 100% with
> Larry on this one too.
>
> I don't really have a strong opinion on the other issues Larry raised,
> even though I agree with most of them.
>
> Em quinta-feira, 27 de outubro de 2016 18:29:53 UTC-2, David Négrier
> escreveu:
>>
>> 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>:
>>>
>>>> > 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/e14f60eb-a73c-45c5-a135-77fc9a074960%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
