[REVIEW] PSR-11 Container Interface (Take 3)

[Matthew Weier O'Phinney]

We are rebooting the PSR-11 review period again as of now; this marks
the third review period, and it will end at 11:59 UTC 29 Jan 2017,
with the prospect of holding a vote starting the following day.

The only change since the previous review period is a clarification of
the role of `NotFoundExceptionInterface`. Previously, the
specification stated that calls to `get()` MUST NOT allow such
exceptions to bubble out, but must instead convert them to the more
generic `ContainerExceptionInterface`.

The specification now states that `NotFoundExceptionInterface`
instances are allowed to bubble out, and that any call to `get()`
where `has()` would return `false` MUST raise a
`NotFoundExceptionInterface`. This change is more in line with
existing implementations, and focuses on the primary issue faced by
consumers: determining when a service is missing from configuration.

Please review the specification again at this time, and let us know as soon as
possible if you see any remaining problems to address; ideally, please do so in
the next 48 hours, so that we may fit within the FIG 2.0 by-law window.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Daniel Plainview]

> This change is more in line with 
> existing implementations, and focuses on the primary issue faced by 
> consumers: determining when a service is missing from configuration.

In order to determine it, we look in our logs or at debugging page. We read the exception message.

Different exceptions don't make it any harder I think. We still look at the message which may be identical.

That separation was focused on semantic difference.

Catching NotFoundException is perfectly fine, but I wouldn't expect to catch it because of broken service or bad configuration.

If service is broken, I would expect to see it in my logs.

By the way, "bubbling out" is an inaccurate wording.

You can make implementation of container so dependencies of service $id would never throw NotFoundException, but MissingDependencyException.

There will be no "bubbling out" at all.

[Chuck Reeves]

Are you suggesting that 2 different exceptions should be present?  It seems that MissingDependencyException would mean that the $id service exists but cannot be created since that service depends on another service that is not present.  

My thoughts go to Zend\Db\Table\Gateway which needs a Zend\Db\Adapter in order to work.  If the Adapter fails to be created a MissingDependencyException would be thrown in that case

[Daniel Plainview]

> Are you suggesting that 2 different exceptions should be present?  It seems that MissingDependencyException would mean that the $id service exists but cannot be created since that service depends on another service that is not present.  

Exactly. 

However, as it was discussed in the past, I wouldn't suggest to put MissingDependencyException to the spec.

In fact, it can be simple \RuntimeException with proper exception message: as I said above, we read the message in our logs and fix the code/configuration.

It also can be more generic MisconfiguredServiceException, like someone suggested previously. It's matter of taste and should be framework-specific I think.

But NotFoundException is different story and should be present in the spec with proper meaning.

[Chuck Burgess]

LGTM...

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myUw060Nrvytzb7N-3Sc7%2BhdA5B6YTmzdOJ5NYjDtsRd_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Chuck Reeves]

Hope it is not too late but I would like to have a quick talk about merging containers.

How would a user merge in containers?  From what I hear it was going to be by merging the configs. What if there is a container from a library that needs a specialized factory that is added when the container is constructed?

Would we want to say that lib has implemented the spec wrong? 

[Matthew Weier O'Phinney]

On Mon, Jan 30, 2017 at 3:23 PM, Chuck Reeves <chuck....@gmail.com> wrote:
> Hope it is not too late but I would like to have a quick talk about merging
> containers.
>
> How would a user merge in containers? From what I hear it was going to be
> by merging the configs. What if there is a container from a library that
> needs a specialized factory that is added when the container is constructed?
> Would we want to say that lib has implemented the spec wrong?

Configuration of a container falls outside the PSR-11 spec,
deliberately. The authors of PSR-11 are working on a specification for
that currently to submit for acceptance at a date in the
not-too-distant future based on the concept of service providers
(https://github.com/container-interop/service-provider).

> --
> 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+u...@googlegroups.com.

> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/84a3df35-c189-45c6-be5a-6228a30ea519%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.