This patch bumps the minimum supported PHP version to 7.2 and adds parameter typehints to ContainerInterface, as the first step towards adding explicit typehints based on the specification.

See https://www.php-fig.org/blog/2019/10/upgrading-psr-interfaces/

NOTE

Since there is no 1.2.x branch, this PR targets 1.1.x.

Description

With v1.2.0 container-interop/container-interop which was released in 02/2017, the package was abandoned. It fully complies with psr/container. Replacing it while keeping BC by adding class_alias will help upstream projects to finally get rid of container-interop/container-interop dependencies.

Closes #37

Here is the history:

Version 1.0.0

The extension interface did not extend \Throwable

Version 1.1.0

The extension interface did extend \Throwable

Version 1.1.1

The extension interface did not extend \Throwable.

[..] as it leads to inheritance issues when child classes implement the Throwable interface in addition to ContainerInterface under PHP versions prior to 7.4.

Version 2.0.0

The extension interface did extend \Throwable as it should since it is a new major release and we don't need to consider edge cases with the BC layer.

Version 2.0.1

The extension interface does not extend \Throwable.

Removes extension of Throwable in the ContainerExceptionInterface to prevent issues under PHP versions < 7.4, where having a concrete instance extend Throwable as well as ContainerExceptionInterface can lead to E_FATAL.

Except for adding 3 type hints, these are the only changes in this repository. How can I, as an open source maintainer, reliably depend on this package? Or how can I, as a user that like static analyses, know what exception to catch? Catching NotFoundExceptionInterface or ContainerExceptionInterface is technically not valid.

I understand that there was things nobody could expect when releasing 1.1.0. But in my opinion it was a misstake releasing 1.1.1 and 2.0.1. It is way better being predictable and slightly wrong.

Im not seeking to put blame nor do I require an explanation

I just want us to be aware of this and focus on 2 things moving forward:

1. Better and longer review processes. It was just a few hours between 1.1.0 and 1.1.1. I doubt there was a chance for a public review and to consider the consequences.
2. Version 3 must extend \Throwable

Starting with PHP 7.2, parameter type widening allows us to omit type-hint in implementations.

This gives us a unique opportunity: we are now able to create a ContainerInterface that has scalar type-hints while retaining compatibility with all implementations. Since usage of scalar type-hints is one of the most requested features of PSR-11, we can fulfill that demand.

We can do this only from PHP 7.2. This PR proposes to:

• bump package version to 1.1
• bump minimum PHP version to 7.2
• add type hints to get and has

Composer will do its job and solve dependencies by itself. If PHP < 7.2 is used, it will install psr/container 1.0.x. If PHP 7.2+ is used, it will bump the version to psr/container 1.1.x.

Users running composer with PHP 7.1 and composer update --ignore-platform-reqs (I know some!) will certainly have a surprise, so we might want to write a blog post somewhere explaining what to do before merging this.

As a side effect, since we now are using PHP 7, we can rewrite the ContainerExceptionInterface to extend Throwable. This is a best practice as it prevents using this interface on anything but an Exception.

This PR does not add a "bool" return type on has as this would introduce a compatibility break that is not worth bumping to a major version (this would split the PHP ecosystem in 2 and we don't want to do that).

Closes #19 Closes #12

This patch builds on #27 and requires a release of ~~2.0.0~~1.1.0 before merging.

The patch adds a return type hint to ContainerInterface::has(), per the already documented specification, in preparation for a ~~v3~~v2 release. No other methods were eligible, as they specified mixed.

See https://www.php-fig.org/blog/2019/10/upgrading-psr-interfaces/

I've run into some static analysis issues because the ContainerExceptionInterface provides no guarantee that it's actually throwable (or catchable more specifically).

I understand making it extend Throwable would break BC, so I think this would be the ideal middle ground, providing the benefit of stricter typing only where it's available.

Hi,

In version 1.1.1, PHP version requirement was the following:

"php": ">=7.2.0"

In version 1.1.2, it was changed to the following:

"php": ">=7.4.0"

What happens if there is a critical security issue that is fixed in a future release (e.g. 1.1.3)? Projects based on PHP <=7.3 won't be able to upgrade.

If the reason is that PHP 7.3 will soon be EOL, debian buster uses it and is still maintained (EOL date 2022-08).

Thanks

upgrade to version 1.1 broken many sites:(

Edit by @mnapoli

Here is the exception message:

PHP Fatal error: Class Symfony\Component\DependencyInjection\Exception\ExceptionInterface cannot implement previously implemented interface Throwable in vendor/symfony/dependency-injection/Exception/ExceptionInterface.php on line 22

Since this PSR discourage the service locator pattern, thereby making it so that libraries don't interact with the container, how does this PSR promote interoperability?

It seems to me that interoperability for libraries is achieved if library authors simply request interfaces in their constructor?

Hi,

What do you think about templating the container interface?

Roughly https://psalm.dev/r/41be1515c2, but perhaps using vendor specific prefixes for param/return :)

I want to propose to start discussion about moving the version to the next major with enabled typehints, so all new libraries and frameworks could rely on more stable and type-hinted interface.

Stupid question: why doesn't the interface provide a "set" method? I wonder what the use case for the interface is if I can't rely on a contract about how objects can be stored in the container?

See similar question on SO at https://stackoverflow.com/q/61504435/6161354.

Thanks for clarifying.

Hey there,

I am working on https://github.com/laminas/laminas-servicemanager/pull/96 and realized that it would be quite simple to fully replace the abandoned package container-interop/container-interop by using some composer magic:

https://github.com/laminas/laminas-servicemanager/pull/96/files#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34R87 https://github.com/laminas/laminas-servicemanager/pull/96/files#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34R52 https://github.com/laminas/laminas-servicemanager/pull/96/files#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34R61

When adding the autoload file to the autoloader like this, all packages type-hinting against the container-interop interfaces will still work and thus, no one will get composer warnings of the abandoned package container-interop/container-interop anymore.

<?php

declare(strict_types=1);

use Interop\Container\Containerinterface as InteropContainerInterface;
use Interop\Container\Exception\ContainerException as InteropContainerException;
use Interop\Container\Exception\NotFoundException as InteropNotFoundException;
use Psr\Container\ContainerExceptionInterface;
use Psr\Container\ContainerInterface;
use Psr\Container\NotFoundExceptionInterface;

class_alias(ContainerInterface::class, InteropContainerInterface::class);
class_alias(ContainerExceptionInterface::class, InteropContainerException::class);
class_alias(NotFoundExceptionInterface::class, InteropNotFoundException::class);

In v1.2.0, container-interop only extends the PSR-Interfaces and has no own methods.

Is this something which would be considered by this component? I know its not the usual way of handling such problems but I'd say it would be "cleaner" in this component than in the laminas/laminas-servicemanager component.

Feedback welcome. If this is not something you want to do in this package, feel free to close this issue as invalid.

It's seems rather weird that an exception which relates to a container has no means of retrieving the container instance. I suggest adding getContainer() to ContainerExceptionInterface, which would return ContainerInterface|null, just in case there really somehow isn't a container associated with it for some reason.

PSR Logger has a Null Logger which can be used easily for testing purposes.

Is there any thought about creating a Dummy/Test/Null container for the same reasons?