Using an alias does not properly look into the Service Providers about container HOT 13 CLOSED

You're actually trying to alias an interface to an implementation. I do the following:

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

from container.

So I register both the UserMapper and UserMapperInterface in the same service provider.

from container.

The issue here isn't with the definition of UserMapperInterface but with the dependencies of the concrete UserMapper it has a constructor dependency of Spot\Locator so you need to make sure that is injected, something like the following.

$container->add('App\Authentication\UserMapperInterface', 'App\Users\UserMapper')
          ->withArgument('Spot\Locator');

from container.

Then I usually do this:

$this->container->add('App\Authentication\UserMapper')
    ->withArgument('Spot\Locator');

$this->container->add('App\Authentication\UserMapperInterface', function () {
    return $this->container->get('App\Users\UserMapper');
});

edit used $this->container instead of $container

edit from philipobenito good point on the scoping, also added a return for the benefit of the OP.

from container.

@hannesvdvreken that's probably the best solution yes, you'll need a use ($container) in there but that's how I'd do it then you're keeping your concrete seperate from the abstraction. 👍

@nebulousGirl the example in @hannesvdvreken comment above will work perfectly, if Spot\Locator also has dependencies you will also need to define them in a similar way.

from container.

What I find confusing is that $container->get('App\Users\UserMapper') does reflection and works without me having to add it to the container, but the following doesn't work?

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

I was expecting the same reflection behavior in both scenarios.

@philipobenito I can settle with your code example, just thought it could improve usability from a developer's point of view.

from container.

@nebulousGirl it was a conscious decision as reflection is slow so the idea is that if you define something, you can be aware that it's not going to reflect, that way the user has a clear choice and there's no real ambiguity about what's happening in the background.

from container.

Also, you can use the container for something like this:

$container->add('key', 'value');
$container->get ('key');

So the container can't know when you're trying to alias something or not. I suggest an alias method that adds a new closure to the container. As I described here before.

from container.

@philipobenito Ok, I understand your point. Is it possible to turn off reflection completely, at least from the get method?

I would prefer to have the same behavior all the time, it would be less confusing.

from container.

It's something I'm playing about with on v2 (due in the next week or so), possibly having 2 separate methods, get and reflect to make it clear what is happening.

from container.

That would be great. Keep up the good work, I'm eagerly awaiting v2 of Container and Route.

from container.

I got caught out by this limitation on the weekend. I'm interested to hear how v2 is going.

I'd also suggest adding something to the documentation if it does change. An example on binding a concrete to an interface in the Auto Dependency Resolution section would be useful!

from container.

I don't think it would be prudent to backport any of this to v1 but v2 has been built around the idea of being much more explicit about when and where reflection will happen, this is mainly to allow for compilation of an immutable container with no abiguity of what is being resolved. I'll close this now as my development copy will be pushed to master hopefully over the weekend with a period of time set aside for discussion and improvements before tagging the release.

from container.