Question: where to define inflectors? about container HOT 11 CLOSED

so there will be a BootableServiceProviderInterface. but what if I'd have this:

class AppServiceProvider extends \League\Container\ServiceProvider implements \League\Container\ServiceProvider\BootableServiceProviderInterface
{
    public function register()
    {
        //
    }

    public function boot()
    {
        $this->container->inflector(ContainerAwareInterface::class)
            ->invokeMethod('setContainer', [ContainerInterface::class]);
    }
}

class EventingServiceProvider extends \League\Container\ServiceProvider implements \League\Container\ServiceProvider\BootableServiceProviderInterface
{
    public function register()
    {
        //
    }

    public function boot()
    {
        $object = $this->container->get(ContainerAwareObject::class);
        // ...
    }
}

What if these are registered in the opposite way? There's shouldn't be a order constraint between serviceproviders.

from container.

@hannesvdvreken do you have a suggestion on how to achieve this? As it is, for eager loading there has to be an order constraint.

from container.

Nah, I don't know. When you want to simply define this SP and make it work:

class AppServiceProvider extends \League\Container\ServiceProvider
{
    protected $provides = [ContainerAwareInterface::class];

    public function register()
    {
        $this->container->inflector(ContainerAwareInterface::class)
            ->invokeMethod('setContainer', [ContainerInterface::class]);
    }
}

You'd need to go up the inheritance tree for every resolved object to see which interfaces it implements and which classes it extends. That's a potentially expensive reflection operation.

Maybe, just maybe:

class ServiceProvider
{
    protected $inflectors = [ContainerAwareInterface::class];

    public function hasInflectorsFor($object) {
        foreach ($inflectors as $inflector) {
            if ($object instanceof $inflector) {
                return true;
            }
        }
        return false;
    }
}

from container.

Once you start looking in to bypassing order constraints more than I already have with the lazy loading (I know this doesn't help for inflectors) then the complexity really starts to grow.

I'm improving inflector functionality this week and that might help the situation from a user land perspective so I'll give you a shout once I've pushed that stuff.

from container.

Great. No pressure. Just letting you know how I use it and what real life problems arise ;-)

from container.

Appreciated 👍

from container.

If it stays like it is now, also fine.

from container.

What I'm thinking is that there is now a service provider aggregate that stores all service providers, a second argument could be passed to the addServiceProvider method that are the dependency service providers of the one you are registering. That way, before register is invoked, the register method of the dependencies will be invoked (if they haven't been already).

from container.

Or they could be defined in the service provider itself in a similar way to the provides array/method. Thoughts?

from container.

Not a fan of that. Service Providers don't really have to know which other SP can register something. If I want to hand the container my own Service Provider which builds a certain type of object in a much better way with my own dependencies...

from container.

Yeah, that's my thoughts, it's too much, but it is the only way around the order constraints if we want to keep lazy loading, which I do.

from container.