Hi all, for the shake of trying (meaning I come here with no announcement at all that this is going to be merged), here is what this currently looks like on the Symfony container: https://github.com/symfony/symfony/pull/21265
the exception part is really where things start to look like a zoo. Because we have many animals there in the "Exception" namespace, and mapping them to PSR11's NotFoundExceptionInterface is going to be non trivial and never perfect I'd say. If you read the thread, you'll see that this sentence "Exceptions directly thrown by the container" is unclear for now - what does "directly" mean? the NotFoundExceptionInterface triggered by the inner get call SHOULD NOT > bubble out. Fortunately enough, this is only a "SHOULD NOT", so we can do as we want and still be compliant. Because I agree with Larry here, the wording is so abstract that in practice it hardly helps. What does missing mean? Eg does a brokenly configured first level service qualify as such? Reasoning from the inside of the container, you may say no. But reasoning from the outside, the user might expect a yes, so that eg a chained-container can continue with the next container in the chain (provided NotFoundExceptionInterface VS ContainerExceptionInterface could be the trigger to decide if the chain should break or continue? what is it for otherwise? doesn't that concept duplicate the "has()" method?) > "Don't standardize an *exception interface* for a known error case because > *nobody* can think of a reason you'd catch that" > Larry just gave one: better error handling. Error handling is one of the very well done part of PSR-6 - far better that eg how Doctrine Cache behaves. (eg when caching unserialisable objects, PSR-6 tells what to do). Excellent error handling is a *strong* argument to me and a requirement for a standard to me. - It is useful for routers to fetch a controller from the container. > What "id" should the router "get()"? > - It is useful for writing adapters extending any containers. > - It is useful for composing containers. > Sure - this is a very very thin and specific use case though to me. Nothing as big as other accepted PSRs. > - It is useful for writing factories that do not depend on a particular > container. > Same here: what "id" should such factories "get()"? If this is left to the implementer, it means PSR11 doesn't solve anything for this use case (and the router one). Also, I'd like to make a parallel with PSR-7 and PSR-15. PSR-7 is already > useful by itself, but it will be immensely more useful when PSR-15 passes. > It is the same with PSR-11. It will be the cornerstone of interoperable > service providers. As soon as PSR-11 passes, we plan forming a working > group on standardizing service providers (see > https://github.com/container-interop/service-provider/ for more details). > PSR-11 is a prerequisite. > This is running in circle to me - self referencing statements to me. PSR-15 does not exist, thus it can't justify PSR-11. And looking at PSR-15, how does it solve the "what "id" should the service provider "get()" from the container?" Last note, but not least: having the experience of implementing PSR-16 and PSR-6, I *really strongly* suggest that next PSRs, this one included, always come with a reference battle-ready test suite. We now have one that we share with php-cache on Symfony. And if we've had it before the acceptance, I would eg have been more insistent on the need for the "array" type hint on "*Multiple" methods there, because "array|Traversable" is NOT easily resolved with iterator_to_array. That's what I thought on the first implementation I submitted here. Then tests reminded me that iterators can be non-rewindable - and that keys can be of arbitrary types. And that it's a nightmare to deal with - thus PSR-16 is NOT going to be easy to correctly implemented - which is bad for a standard IMHO. So, back to PSR11, it'd be great - if not mandatory to me - to have a reference test suite that provides actual side effects and verifiable outcomes for every single sentence in the RFC. That would clearly help implementers understand the sometimes too abstracts words - as spotted before. Cheers, Nicolas -- 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/CAOWwgpmbJPuG%3DKEw3%3DTiajc8CfFSj84CPdwB8ooNWoJNEfGSHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
