This PR provides functionality for Service Providers and addresses #12.

Usage

Simplest use case would be to build a service provider and register an instance of that.

<?php

namespace Acme\ServiceProvider;

use League\Container\ServiceProvider;

class SomeServiceProvider extends ServiceProvider
{
    protected $provides = ['some.service'];

    public function register()
    {
        $this->getContainer()->add('some.service', 'SomeService');
    }
}

$container->add(new Acme\ServiceProvider\SomeServiceProvider);

// resolve the service provider by the name registered
$container->get('some.service');

Lazy Loading

You can register a service provider by string reference to the fully qualified namespace of the service provider. The addServiceProvider expects you to provide a name/alias as the first argument.

$container->addServiceProvider('Acme\ServiceProvider\SomeServiceProvider');

$container->get('some.service');

This PR aims to be a discussion platform for version 2 of the container over the coming 2 weeks before a release is tagged on Friday 28th August 2015.

It is incomplete and will be added to over the coming days with a completed test suite and any missing functionality.

The main talking points I'd like to discuss are as follows:

• Should "auto-wiring" be removed? I see three options
  1. Remove reflection completely (my preferred option).
  2. Attempt reflection as the last step of object resolution (turned off by default).
  3. Attempt reflection as the last step of object resolution (turned on by default).
• The question of config. I've had several conversations with people requesting a better way to interact with the container via array type configs. This is something I've decided to include, but, should it be via new methods or by refactoring the current methods so that they can be invoked with different types of arguments then a simple array_map can pass the config to them as a callable?

There will be more discussion over the coming days, but these two issues are my main concern as they are blockers to finishing the functionality.

Please don't provide any edits to the code as of yet without discussion around it but if there is something you'd like to get involved with then please bring it up here so that it can be properly assigned and attributed.

Hi,

It would be great to allow a way to have the inflector use a factory closure to create classes that implement an interface or extend a base class x.

For instance:

use My\ClassInterface;

$container->inflector(ClassInterface::class, function ($container, $concrete) {
    return ClassFactory::create($concrete);
});

What is your thought on that?

This PR

• [x] allows to protect a container to prevent adding services, service providers, and inflectors

:information_desk_person: It's still possible to override services, though, by creating a new container, defining services there, and delegating to the original container. Not sure, should delegating to a locked container be prevented, maybe?

The $container field is type-hinted as \Psr\Container\ContainerInterface, which means you can't have a legal ServiceProvider implementation that does this:

class FooServiceProvider extends AbstractServiceProvider {
    protected $provides = [
        ValidatorInterface::class,
    ];

    public function register()
    {
        $this->container->share(ValidatorInterface::class, Validator::class);
    }
}

Both phpstan and PhpStorm complains that there is no method named share() on $this->container. I'm not sure if the correct fix is to change just the member variable's type-hint or the setContainer() and getContainer() methods too.

It doesn't seem to make sense to swap out the League\Container for some other PSR compatible container in a service provider specifically designed for this package, so maybe the whole ContainerAwareInterface needs some changes?

Hi there

Is there any tutorial on how to use ContainerAwareInterface ?

I try to pass the container object to my Controller class.

I cant find any tutorial on that..Please advice

Here what i tried:

Controller class:

<?php namespace App\Core;

use League\Container\ContainerAwareTrait;
use League\Container\ContainerAwareInterface;

class AppController implements ContainerAwareInterface
{
    use ContainerAwareTrait;

    public function __get( $name ) {

        var_dump($this->container);
        exit;

        if ( $this->container->has( $name ) ) {
            return $this->container->get( $name );
        }
    }
}

Bootstrap script:

$container = new Container();

#Auto-wiring based on constructor typehints.
#http://container.thephpleague.com/auto-wiring
$container->delegate( new ReflectionContainer() );

$container->inflector( 'ContainerAwareInterface' )
    ->invokeMethod( 'setContainer', [ $container ] );

I got the following when i try dump the container object

/var/www/html/foo/src/App/Core/AppController.php:12:null

Hi, not quite sure if it's just me being stupid or this just not being possible:

use League\Container\Container;
use League\Container\ServiceProvider;


class MyServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->getContainer()['key'] = 'value';
    }
}

$container = new Container();
$container->add(new MyServiceProvider);
var_dump($container->get('key'));

It throws:

Fatal error: Uncaught exception 'League\Container\Exception\ReflectionException' with message 'Unable to reflect on the class [key], does the class exist and is it properly autoloaded?' in /Volumes/Data HD/Dropbox/Projects/snap/vendor/league/container/src/Container.php on line 401

I've used Pimple in the past and this seems to work just fine :confused:

The commented line throws an error: Argument 1 passed to App\Users\UserMapper::__construct() must be an instance of Spot\Locator, none given. And the second line works properly, but defeats the purpose of lazy loading.

// $container->add('App\Authentication\UserMapperInterface', 'App\Users\UserMapper');
$container->add('App\Authentication\UserMapperInterface', $container->get('App\Users\UserMapper'));

The problem seems to be with Spot\Locator being registered in a service provider. Using the commented line, the container does not look into the providers to find the service, like it does when using the get method

Environment:

• Windows 10 x64
• PHP 8.0.1
• Package Version 3.3.4

So far in most cases where I'm using the Container, it seems to work pretty well. But I'm starting to get instances where the reflection just stops working altogether.

In many cases simply binding a concrete class to an abstract interface, or just sharing a concrete class on its own, just works. But it's behaving very inconsistently with some new structures I'm adding to my application.

For instance, I'm now having to explicitly set constructor arguments. In other places in my code, this does not have to be done.

$adapterDefinition = $container
	->share(ExceptionResponseAdapter::class)
	->addArguments([
		ResponseFactoryInterface::class,
		StreamFactoryInterface::class
	]);

I can retrieve and dump instances of those requirements before creating this definition and the container resolves them without issue, so I know it's not a matter of those dependencies failing to resolve. However, not explicitly setting the arguments here results in a 'too few arguments' error.

Likewise, it doesn't attempt to resolve dependencies with addMethodCall being given a class name, and instead passes said class name directly to the method, which obviously fails with a type error.

$adapterDefinition->addMethodCall('pipe', [$strategy]);

I have again confirmed that it's able to successfully resolve the $strategy independent of this, so I know the dependency isn't failing, and the container is simply refusing to follow instructions.

I assumed nobody used this:

$container->invokable('closure', function ($arg1, $arg2) {
   ...
});

$container->call('closure', ['value1', 'value2']);

But this is backwards compatible:

$container->add('item', function ($arg) {
   return $arg;
})->withArguments('default_value');

echo $container->get('item');
// 'default_value'

echo $container->get('item', ['override']);
// 'override'

Fixes #32.

I had an issue where I had put

$this->container->inflector(ContainerAwareInterface::class)
            ->inflect('setContainer', [ContainerInterface::class]);

inside the register method of a ServiceProvider. The register method wasn't called because the resolved object wasn't referenced in the container as a ContainerAwareInterface implementation object.

I tried using ReflectionDelegate to achieve auto-wiring and it works mostly great. The issue occurs when I register some services as shared – then they won’t be autowired any more.

See the following simplified example:

<?php

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

class Logger {
    public function __construct(string $name) { }
}

class Authentication {
    public function __construct(Logger $logger) { }
}

class AboutController {
    public function __construct(Authentication $authentication) { }
}

$container = new League\Container\Container();

// Register the reflection container as a delegate to enable auto wiring.
$container->delegate(new League\Container\ReflectionContainer(true));

$container
    ->add(Authentication::class)
    ->setShared()
;

$container
    ->add(Logger::class)
    ->addArgument('selfoss')
    ->setShared()
;

var_dump($container->get(AboutController::class));

Fatal error: Uncaught ArgumentCountError: Too few arguments to function Authentication::__construct(), 0 passed and exactly 1 expected in test.php:10
Stack trace:
#0 [internal function]: Authentication->__construct()
#1 src/Definition/Definition.php(212): ReflectionClass->newInstanceArgs(Array)
#2 src/Definition/Definition.php(175): League\Container\Definition\Definition->resolveClass('Authentication')
#3 src/Definition/Definition.php(154): League\Container\Definition\Definition->resolveNew()
#4 src/Definition/DefinitionAggregate.php(79): League\Container\Definition\Definition->resolve()
#5 src/Container.php(175): League\Container\Definition\DefinitionAggregate->resolve('Authentication')
#6 src/Container.php(118): League\Container\Container->resolve('Authentication')
#7 src/Argument/ArgumentResolverTrait.php(45): League\Container\Container->get('Authentication')
#8 src/Argument/ArgumentResolverTrait.php(107): League\Container\ReflectionContainer->resolveArguments(Array)
#9 src/ReflectionContainer.php(58): League\Container\ReflectionContainer->reflectArguments(Object(ReflectionMethod), Array)
#10 src/Container.php(203): League\Container\ReflectionContainer->get('AboutController')
#11 src/Container.php(118): League\Container\Container->resolve('AboutController')
#12 test.php(33): League\Container\Container->get('AboutController')
#13 {main}
  thrown in test.php on line 10

I could addArguments the dependencies explicitly but doing it for all of the shared services would be annoying.

This change removes the deprecated warning for ReflectionParameter::getClass in PHP 8 and adds support for nullable arguments.

This change was taken from the 3.x branch.

It seems that #220 fixed #219 in the 3.x branch but the bug still exists in the 4.x branch.

https://github.com/thephpleague/container/blob/388e992884ab75632d93dbaf4d29ec024d64b964/src/ServiceProvider/ServiceProviderAggregate.php#L72-L75

Resolves https://github.com/thephpleague/container/issues/237

To summarise that issue:

• PHP class names may be valid in both the format Foo\Bar and also as \Foo\Bar when used as a string
• Using Foo::class returns Foo\Bar but legitimate user code may handle as \Foo\Bar and this would work for class_exists or new $var cases
• Because of this, a concrete class may be set with one form of slash, and got with the other. This means the set definition is not used.
• This fix adds test for both ways round that this issue could occur, and implements the class name normalizing in each appropriate place

This aims to be backwards compatible and causes no test failures.