Certainly feels as though the separation of container-get from container-set has caused a lot of disagreement, here. It also looks like there's a *lot* of feedback here saying there need to be at least two interfaces in container-set - SharedContainer and FactoryContainer - and that many projects will need (or at least probably choose) to wait until they can rely on one or both of those to actually use a container PSR.
In the meantime, other projects will likely be satisfied with PSR-11 more or less as-is, if for no other reason than to claim support for it. I imagine almost all of these will be frameworks and similar libraries, or container libraries themselves. Other projects, especially end-user projects, will see far less utility in a get-only PSR, and will therefore delay adoption until the set portion is ready as well. Which, near as I can see, is fine for the aims of this particular PSR, which seems to be designed more for frameworks than for application developers. As to the specific question asked here, either option 1 or 3 would fit best, with 3 being more explicit in the expected behavior of a compliant implementation, especially as regards the need for further verification of how the container is configured (be that via implementation or interface). I'd probably mention the -set interfaces in there somewhere as a point of reference (the PSR can be amended with the actual number(s) when such is/are assigned), but that's me; it may not be desirable in this context. -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFjuE%2BnyiA8Pb7MUZWWS0JgHOkz%3Dh0C0qSEeSgRMuS6D%3Djd3Wg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
