php-fig/container

container's Issues

ContainerExceptionInterface is not throwable

Hello. I have been following PR #20 and I see that the exception interfaces will extend Throwable in it, along with the breaking changes with type-hints. However, the static code analyser phpstan is now reporting that the exception interface is not a subtype of Throwable as its an error:

PHPDoc tag @throws with type Psr\Container\ContainerExceptionInterface is not subtype of Throwable

Is there a possibility to fix this outside of PR #20 ? I'm not familiar with any bylaws of FIG and what the possibilities are.

Should get resolve concrete identifiers?

According to the PSR, get will

throws an exception if the identifier is not known to the container.

Given a call to the container $container->get(Foo::class); and the fact that Some\Package\Foo is instantiable (it's a concrete class), should the container resolve it or throw NotFoundException? Of course, the scenario to be discussed is only of interest in case Foo::class has not been registered in the container before (it's unknown to the container), otherwise the question would be stupid.

namespace Some\Package;

class Foo
{

}

Can't pull the package in via composer/packagist

I am currently trying to pull this package in via composer like so:

composer require psr/container

from:

https://packagist.org/packages/psr/container#dev-master

But I am gettingt the following error:

Problem 1
│ - The requested package psr/container could not be found in any version, there may be a typo in the pa
│ckage name.
│
│Potential causes:
│ - A typo in the package name
│ - The package is not available in a stable-enough version according to your minimum-stability setting
│ see https://getcomposer.org/doc/04-schema.md#minimum-stability for more details.

Is there something wrong here? I can pull in other packages fine.

Question: Why there is no set method?

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.

Error composer version

I started getting the following error because now this parquet in its last tag added that it needs php>=7.4

The php version change should be in a version 3.0 and not in 2.0.2

'-Interface' suffix on exceptions is inconsistent with other PSRs.

There's no '-Interface' suffix in other PSRs with exception interfaces.
Should PSR-11 follow those PSRs?

What is the purpose of `has`?

I've read through a bunch of topics on container-interop and here that you guys talked A LOT about auto-wiring. Unfortunately the issue keeps popping up on Laravel because we decided that the container only returns true on has if objects are explicitly bound. One of the editors himself pointed it out here laravel/ideas#803.

One thing I did not find in the discussions was usage instead of implementations and it's likely that you guys can point me to the right direction.

Suppose the following usage:

if ($container->has($identity)) {
    try {
        $concrete = $container->get($identity);

        //
    } catch (Psr\Container\ContainerExceptionInterface $e) {
        // This will never be a NotFoundExceptionInterface
    }
} else {
    // Not Found
}

Although a NotFoundException will never be thrown, a ContainerExceptionInterface can still be thrown. How much value did has added here versus the following:

try {
    $concrete = $container->get($identity);

    //
} catch (Psr\Container\ContainerExceptionInterface $e) {
    if ($e instanceof NotFoundExceptionInterface) {
        // Not Found
    }
}

My point being: When using $container->get($identity);, a try-catch is basically a must-have and the value of has can still be achieved, if desired. What am I missing that makes me think has do more harm than good?

Interface suffix?

The spec uses it, the code does not. Is this being debated or has a decision already been taken about whether to add this suffix or not?

Have Dummy/Test Container for testing purposes?

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?

Prepare version 2.0.0 of container interface with enabled strict types.

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.

Compatibility with scalar type hints

It should be possible to support PSR-11 using:

<?php
class Container extends \Psr\Container\ContainerInterface {
    public function get(string $id)
    {
        // ...
    }

    public function has(string $id)
    {
        // ...
    }
}

Any ideas?

Replacement for container-interop

Hey there,

I am working on laminas/laminas-servicemanager#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.

PHP version requirement was changed in a patch version (1.1.2)

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

Add `ContainerException::getContainer()`

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.

Fatal error with v1.1.0 and PHP 7.2 / 7.3

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

Purpose of this PSR is moot?

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?

Exception interfaces should extend Throwable

When running Static-Analysis like Psalm, they will report an invalid catch statement:

InvalidCatch: Class/interface Psr\Container\NotFoundExceptionInterface cannot be caught

This happens because the Interfaces do not extend Throwable. This is correct since classes that do not implement Throwable cannot be used with throw: https://3v4l.org/NNDeW

ContainerAwareInterface

What about to have this interface?
With this we can do lazy passing the container to a service like the Psr\Log\LoggerAwareInterface

Why are you bumping minimum php in patch releases?!

This is literally a backward compatibility break and should never happen in a patch release.

Templated container

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 :)

The exception is not implementing Throwable

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

Why dependency on PHP 7.4.0

Hi,

I'm unable to understand why this package psr/container require PHP 7.4.0 as its just collection on some interfaces. I think it should require not more than php: >=5.4.0

Thanks!