The dependency injection container for humans

<?php

declare(strict_types=1);

use function DI\autowire;

use DI\ContainerBuilder;
use function DI\factory;

require_once __DIR__.'/../vendor/autoload.php';

class Fu
{
    public function create(): self
    {
        return new static();
    }
}

class Bar
{
    public function create(): self
    {
        return new static();
    }
}

class FuBar
{
    private $fu;

    private $bar;

    public function __construct(Fu $fu, Bar $bar)
    {
        $this->fu = $fu;
        $this->bar = $bar;
    }
}

$builder = new ContainerBuilder();
$builder->enableCompilation(__DIR__);

$builder->addDefinitions([
    FuBar::class => autowire()
        ->constructorParameter('fu', factory([Fu::class, 'create']))
        ->constructorParameter('bar', factory([Bar::class, 'create']))
]);

$dic = $builder->build();

In CompiledContainer.php you'll find

    protected function get3b62a97e28ef909b96b42a793be8a616()
    {
        $object = new FuBar($this->get5ffee756f39d463eb2a0c22906c0f2be(), $this->get5ffee756f39d463eb2a0c22906c0f2be());
        return $object;
    }

As you can see the definition for Bar (Method get5ffee756f39d463eb2a0c22906c0f2be) is used for every Parameter in FuBar::__construct.

I was able to nail the issue down to \DI\Compiler\Compiler::getHashedValue. In this scenario the parameter string $value is <nested definition>Factory for every factory definition used like above.

In our case this is a crititcal issue, downgrading to 6.0.6 fixed this.

Relates to #605

Must haves:

• minimize BC breaks as much as possible (upgrading should be easy!) - when I say "rename" below, I mean we keep the old names to preserve BC but we deprecate them
• drop support for PHP 5.4 #361
• solve the object() helper that does too much and is too magic

What about PHP 5.5?

Main ideas:

Support PHP 7 and above only?

Remove scopes: #409

Rename a few helpers to actions:

• factory() -> call()
• object() -> create()

This is hopefully clearer on what will actually be done by the container.

Same for object() methods (though I'm a little less convinced of the gain vs effort to migrate):

• ->constructor(...) -> ->parameters(...)
• ->method(...) -> ->call(...)

object() is too magic (#294 extends autowiring and other definitions). We can split its behavior into:

• create(): create an object, doesn't extend autowiring or a previous definition
• autowire(): create an object using autowiring, also allows to set some parameters/method calls
• extend(): extend the previous definition to override constructor parameters/method calls #279 (it might even be removed altogether)

It will be much clearer (less surprises is always better), and we'll be able to add support for "explicit autowiring" where you only get autowiring when using autowire() (optional of course), which I think is really good when you don't want too much magic.

Add a way to set parameters on call() (#362, #239): call(function (...) {...})->parameters(get('abc'), get('def')).

Other ideas:

• migrate the cache to PSR-6? #376

Summary:

return [

    'foo' => get('bar'),

    'foo' => env('FOO'),

    'foo' => string('{root}/test.txt'),

    'foo' => create(MyClass::class),
    MyClass::class => create(),
    MyClass::class => create()
        ->with('param1', get('foo'))
        ->call('setLogger', get(Logger::class)),
    '*Repository' => create('*DoctrineRepository'),

    'foo' => autowire(MyClass::class),
    MyClass::class => autowire()
        ->parameters(get('abc')),
    MyClass::class => autowire()
        ->parameter('param1', get('abc')),
    MyClass::class => autowire()
        ->call('setLogger', get(Logger::class)),

    'bar' => extend('foo')
        ->parameter('param2', get('def')),
    'bar' => extend()
        ->call('setLogger', get(Logger::class)),

    'foo' => call(function () {
        return 'bar';
    }),
    'foo' => call([Factory::class, 'method']),
    'foo' => call([Factory::class, 'method'])
        ->parameters(get('abc')),
    'foo' => call([Factory::class, 'method'])
        ->parameter('param1', get('abc')),

    'api' => decorate(function ($previous, $c) {
        return new CachedApi($previous);
    }),

    'log.handlers' => [
        get(StreamHandler::class),
        get(EmailHandler::class),
    ],
    'log.handlers' => add([
        get(SyslogHandler::class),
    ]),

];

Internal changes:

The configuration array could be turned into an AST and visitors could be applied (to turn it into a proper definition array). Then the resulting processed array of definitions could be cached.

Autowiring and annotation reader might not be "definition source" anymore (so much trouble from the beginning because of this).

That should solve problems of definitions nested in others (#297, #343), making caching easier and much more efficient (cache one array instead of each definition separately), maybe open the door for AST extensions, maybe open the door to compiling? It will also allow "validation passes" for dev environment (e.g. #243).

That config-to-AST part could be written as a separate package. It allows to write any configuration using PHP arrays, it could be useful. For example I needed exactly that for a framework and started a draft of such a thing (https://github.com/stratifyphp/framework/tree/master/src/Config).

Feedback and ideas are welcome!

Hi, we are currently integrating PHP-DI 4 in one of our project.

Because its a good practice to have interfaces for our business services we have to define a lot of PHP-DI interface => implementation mappings.

For exemple (this sample can also be configured using a PHP-DI configuration array) :

    $container -> set('Application\Service\IAuthorAccountService', \DI\object('Application\Service\Impl\AuthorAccountService'));
    $container -> set('Application\Service\IAuthorNbReadingService', \DI\object('Application\Service\Impl\AuthorNbReadingService'));
    $container -> set('Application\Service\IAuthorPublicationService', \DI\object('Application\Service\Impl\AuthorPublicationService'));
    $container -> set('Application\Service\ILastUpdatedService', \DI\object('Application\Service\Impl\LastUpdatedService'));
    $container -> set('Application\Service\IMailService', \DI\object('Application\Service\Impl\MailService'));
    $container -> set('Application\Service\IPublicationNbReadingService', \DI\object('Application\Service\Impl\PublicationNbReadingService'));
    $container -> set('Application\Service\ISubjectNbReadingService', \DI\object('Application\Service\Impl\SubjectNbReadingService'));

This is correctly working but at the end we will have a lot of mappings even if we have only one instance of our business services in the DI container.

I think a really good improvement for future releases of PHP-DI would be to have an auto-scanning feature to scan classes with the @Injectable annotation. This is exactly what the Spring Framework does.

For example in Spring we can do the following to automatically scan classes using the @Component annotation and create an instance of each component in the DI container at starting :

     <context:component-scan base-package="application.service.impl" />

For this reason interface mappgins is not necessary in Spring, each time a @Component annotation is found on a class Spring instanciate this class and injects the associated object inside its DI Container. Then when a @Resource annotation is found on a class attribute Spring look inside its DI container to find one object which implements the specified interface. If multiple objects implementing the interface are present inside the container Spring fails or forces you to define the name of the object to inject.

In PHP-DI it would be great to have something similar, for example :

$container = $containerBuilder -> buildDevContainer();
$container -> scanPackage('Application\Service\Impl');

This would prevent developers to define lots of interface => implementation mappings in PHP-DI.

Any thoughts about this feature ?

Thanks,

Baptiste

Version 3.0

Issues: Issue list

• Configuration is reworked from scratch with different backends
• Provided configuration backends:
  • Reflection
  • Annotations: @Inject, @Injectable
  • PHP arrays
• As a consequence, annotations are not mandatory anymore, all functionalities can be used with or without annotations.
• Setter injection
• Constructor injection
• Scopes: singleton (share the same instance of the class) or prototype (create a new instance each time it is fetched). Defined at class level.
• Code now follows PSR1 and PSR2 coding styles
• More tests
• ...

Hi, I'm beginning to use Zend Expressive and saw a page dedicated to DI Container integration https://zendframework.github.io/zend-expressive/features/container/intro.

I think it would be great to add PHP-DI here too, perhaps by proposing a description / a page to the guys who maintain Zend.

When using lazy loaded dependencies, I encountered some curious behaviour when handing over more parameters to a function than defined in its signature (variadic functions).

class Service
{
    /**
     * @param mixed $param1
     * @param mixed $param2
     * @param mixed $paramN Can be used to supply additional parameters
     */
    public function doStuf($param1, $param2){
        echo func_num_args();
    }
}

Now let's try to use this Service when fetched from the dependency injection container

$dic->get('Service')->doStuff(1, 2, 3); //Prints '3' when not lazy loaded
$dic->get('Service')->doStuff(1, 2, 3); //Prints '2' when lazy loaded

I use this approach to inject extra variables when translating messages like: "User X has logged in on Y", where X and Y would be 'additional' parameters.

This probably has to do with the intermediate proxy classes that are generated. For example from a generated proxy class:

  /**
     * {@inheritDoc}
     */
    public function doStuf($param1, $param2)
    {
        $this->initializer5683c4a86687a054344119 && $this->initializer5683c4a86687a054344119->__invoke($this->valueHolder5683c4a866860700867865, $this, 'fireEventOnOrder', array('param1' => $param1, 'param2' => $param2), $this->initializer5683c4a86687a054344119);

        return $this->valueHolder5683c4a866860700867865->fireEventOnOrder($param1, $param2);
    }

When looking at https://github.com/Ocramius/ProxyManager/issues/177, I think this behaviour is expected. Therefore I think it should be mentioned in the documentation as a warning...

Hi @mnapoli,

During an installation of PHP-DI using composer I noticed that 'ocramius/proxy-manager' is being installed, which brings the dependencies zendframework/zend-code, zendframework/zend-eventmanager, zendframework/zend-stdlib.

As far as I can see I do not need those dependencies because I am not using the proxy functionality; would it make sense to move the ocramius/proxy-manager to the require-dev or suggests so that it is not added by default?

I keep encountering this issue, so I thought I'd have a crack at a fix. Unfortunately it wasn't as simple as it initially seemed, so this is only a test case to demonstrate the issue.

A common pattern we use in my workplace is to have defaulted constructor parameters. We also use interfaces for just about everything, so the class may look something like this:

class Foo implements FooInterface
{
    public function __construct(BarInterface $bar, BazInterface $baz = null)
    {
        if (null === $baz) {
            $baz = new Baz;
        }

        $this->bar = $bar;
        $this->baz = $baz;
    }

    // ...
}

So I would add definitions to our container something like:

return array(
    'BarInterface' => DI\object('Bar'),
    'FooInterface' => DI\object('Foo'),
);

Leaving out a definition for BazInterface beacuse we just want to use the default. Now when you request FooInterface from the container:

$container->get('FooInterface');

You get a nasty exception something like:

Entry BazInterface cannot be resolved: BazInterface is not instantiable

The expected result is that get() returns an instance of Foo using the default value for $baz.

This PR includes a rough integration test that currently fails because of the issue mentioned above. It is not intended to be merged as it doesn't follow the style of your other tests, but should be good enough to aid in diagnosing the cause of the issue.

Thanks!

Here is an example.

Class Foo's constructor requires a value that is not available until a method A is called.

A creates an instance of Foo calls \DI\Container::set to register this instance. Later in the method A, Foo->method(...) is called in directly.

If I make Foo lazy loaded, I still get an exception that Foo can't be instantiated because it is missing a dependency that can't be resolved.

However if I make the classes that depend on Foo lazy loaded, it works. It appears that the proxy will correctly look up Foo in the container in this case.

It's more intuitive and convenient to me to make Foo lazy loaded in this situation. There may be multiple classes that depend on Foo. Is it possible?

Did I miss something?

Hi,

has anyone done any thinking on integrating php-di with the Slim web framework/thingie?

This is basically a Slim web app:

index.php:

$app = new \Slim\Slim();

$app->get('/orders(/:page)', function ($page = 1) use ($app) {
    $app->render('orders.twig', array( 'page' => $page ));
});

I could do it hardcoded of course but was wondering if someone came up with something better.

The container allows values to be overriden in the request context. Values like the response, the current URI, the request itself are overriden in the container if another request comes into place and re-sets these values.

I'm using PHP-DI with Swoole, which allows this kind of behavior, which is probably the future of PHP so I think scopes like .NET Core are a very valid feature to be implemented. Notice that this Scope implementation would be totally different from the previous and removed version, this time Scopes are finally useful.

I created 2 objects of class B. I don't understand why the dependency a of the two objects is the same. When I change the name property of the a dependency of one object, the other object's a dependency also changes. I tried with illuminate/container and it doesn't happen like that "sorry about my english"

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use DI\ContainerBuilder;

try {
    $c = (new ContainerBuilder())->build();

    // Create 2 objects of class B
    $b1 = $c->make(B::class);
    $b2 = $c->make(B::class);

    var_dump(
        $b1 === $b2,       // bool(false)
        $b1->a === $b2->a, // bool(true): Why is the dependency A of 2 objects B is the same?
        $b1->a->name,      // string(7) "default"
        $b2->a->name       // string(7) "default"
    );

    $b1->a->name = 'changed';

    var_dump(
        $b1 === $b2,       // bool(false)
        $b1->a === $b2->a, // bool(true)
        $b1->a->name,      // string(7) "changed"
        $b2->a->name       // string(7) "changed"
    );
} catch (Exception $e) {
    echo "Error: " . $e->getMessage();
}

class A
{
    public string $name;

    public function __construct(string $name = 'default')
    {
        $this->name = $name;
    }
}

class B
{
    public A $a;

    public function __construct(A $a)
    {
        $this->a = $a;
    }
}

The type of container that is actually built may be more specialized than the Container base class. As such, make sure we use the proper return typehints.

I found this issue while testing extensions of the Container class to support a resettable interface, as an alternative solution to #821. This typing issue would arise for anyone trying to extend Container.

This issue also exists in the v7 branch (with a handful of fairly straightforward conflicts from current master). If you would prefer that I target the v7 branch instead, I'd be happy to make that change.

Hello, I am using PHP-DI in my projects for quite some time and I am currently facing an issue with PHP enums. I am using monolog library for logging in my apps. Recently I have decided to update Monolog from version 2.6.0 to 3.2.0. Enum Monolog\Level was introduced in Monolog version > 3, which is now prefered way of how to set what messages should be logged. In one of my apps I am using container compiling. After Monolog upgrade my app stop working with error

Fatal error: Uncaught DI\Definition\Exception\InvalidDefinition: Entry "Monolog\Handler\HandlerInterface" cannot be
compiled: An object was found but objects cannot be compiled
Full definition:
Object (
class = Monolog\Handler\StreamHandler
lazy = false
__construct(
$stream = get(app.log.options.target)
$level = Monolog\Level::Info
$bubble = (default value) true
$filePermission = (default value) NULL
$useLocking = (default value) false
)
setFormatter(
$formatter = get(Monolog\Formatter\JsonFormatter)
)
) in /var/www/vendor/php-di/php-di/src/Definition/Exception/InvalidDefinition.php:19

I was debugging the issue and end up in Compiler class, where it failed when Monolog\Level should be processed.

I can get rid of this issue by passing value of enum in my definitions (e.g. use Monolog\Level::Info->value). Is there something, I am missing or this is general issue for all enums? When compiling is off, everything works with enum just fine.

The purpose of this change is to improve the support for resource management and introspection of the Container class by adding the following methods:

• Container::reset - unsets an entry in the container

• Container::initialized - checks if an entry is initialized

These method names were chosen for consistency with the same features in Symfony's Dependency Injection component.

The idea here is that if you have an entry in the container that is no longer needed (say, for example, a database connection), then you can remove the entry from the container with reset to free the resource. If it is needed again later, no extra work is needed to get it from the container according to its definition, and a new instance will be constructed.

The initialized method is related in the sense that there is no existing way to see if an entry is present in the container. It is distinct from the has method, which only reports if an entry can be supplied by the container, not if it has. You may have some logic that depends on if a resource has been allocated yet (i.e. before the first get or after reset).

Two practical use cases:

1. A long-running API service has a database connection in its container. After a call to the API completes, the database connection is closed to free up resources and ensure that the connection does not time out. Because the database connection in the container is now invalid, careful measures need to be put in place to ensure that a reconnection to the database is performed before the object in the container is used on the next API call. This essentially removes the "on demand" aspect of the database connection, because the call may not even need a database connection. By using Container::reset, no special reconnection scaffolding is needed; the container will automatically create a new database connection regardless of where or when the next Container::get call is made.

2. A logging mechanism for the same API service will log certain properties of the database connection after each call. If no database connection has been opened, then no connection should be made to avoid unnecessary resource consumption. Without the introspection provided by Container::initialized, there is no way to determine if a connection has already been opened through the container interface.

When attempting to run composer install on latest master branch, I am getting the following message…

Loading composer repositories with package information
 Updating dependencies
 Your requirements could not be resolved to an installable set of packages.
 
   Problem 1
     - ocramius/proxy-manager[2.11.2, ..., 2.13.1] require php ~7.4.1 || ~8.0.0 -> your php version (8.1.5) does not satisfy that requirement.
     - ocramius/proxy-manager[2.14.0, ..., 2.14.1] require php ~8.0.0 -> your php version (8.1.5) does not satisfy that requirement.
     - Root composer.json requires ocramius/proxy-manager ^2.11.2 -> satisfiable by ocramius/proxy-manager[2.11.2, ..., 2.14.1].
 
 Failed to install packages for  ./composer.json.

I am using Slim Framework 4 and adding multiple definition files, but getting Circular Errors when I try to decorate() an existing definition from another file.

/var/www/vendor/php-di/php-di/src/Container.php: line 384 if (isset($this->entriesBeingResolved[$entryName])) { throw new DependencyException("Circular dependency detected while trying to resolve entry '$entryName'"); }

All the below files returns an array of definitions, and works fine when I remove definitions_b.php or definitions_c.php, meaning it works fine when there are not more than 2 files trying to define and/or alter the same definition.

$containerBuilder->addDefinitions(['definitions_a.php', 'definitions_b.php', 'definitions_c.php']);

file definitions_a.php

return [
'settings' => function () {
       return ['acme' => 123];
           }
];

file definitions_b.php

use function DI\decorate;
return [
'settings' => decorate(function ($previous, ContainerInterface $c) {
      $previous['settings]['acme'] = 456;
      $result = Db::getOne('app');
      $previous['settings']['color'] = $result->color;
       return $previous;
    }
];`

file definitions_c.php

use function DI\decorate;
return [
'settings' => decorate(function ($previous, ContainerInterface $c) {
       $previous['settings']['acme'] =789;
       return $previous;
    }
];

I do understand the non-related problem of order-of-adding, but would please like your advice on the above.