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:

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

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


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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to