container-interop / service-provider

[EXPERIMENTAL] Promoting container/framework interoperability through standard service providers
71 stars 10 forks source link

Why Require Container? #42

Closed XedinUnknown closed 9 months ago

XedinUnknown commented 7 years ago

Hi!

Why does this package require psr/container? It is not required anywhere by the code. I mean, the only method of the only interface, which does not extend ContainerInterface, neither accepts or returns ContainerInterface.

I am making a stand-alone general-purpose Factory implementation. One of the factory classes will use a service provider to retrieve the definitions. Nothing in my package assumes usage with a DI container. But now I am forced to rely on PSR-11 for nothing.

moufmouf commented 7 years ago

ContainerInterface is part of the signature of the factory methods. PHP is not strongly typed enough to allow us to define the signature of the factories but in my opinion, it is really part of the signature.

I mean... assuming PHP was more "scala-like", the method signature should be:

function getServices() : array<string, function(ContainerInterface $container, function() $previous = null)>

Also, service providers are meant to be "consumed" by containers. And those containers MUST be PSR-11 compliant since they MUST be passed in parameter as the first factory method.

I really don't see a scenario where you could use service-providers without a PSR-11 container at all so it makes sense to me to add this dependency. Maybe I don't understand your particular use case. If you have a link to send me so I can take a look at your project, I could maybe understand better you particular use case?

XedinUnknown commented 7 years ago

@moufmouf, thanks for your reply. Right now, I don't have a project you could look at, besides the project where I aim to implement the concept I described above. A few months ago, I was involved in a discussion about whether the DI container should get() the same instance every time, or a different one every time. Knowing if the instance is the same was critical to me, and is a valid use case for many. It was pointed out to me that this is not the goal of ContainerInterface::get() and I should instead use Factory::make(), which I think makes perfect sense, and so I went with it.

Now I want to make a de-coupled general-purpose factory. I created a standard interface for it, and published it separately, like I always do. I also want to have an abstract implementation separately. This implementation does not care about the standard of Container Interop. Instead, it works with Service Provider. At this point, I just need to be able to set and retrieve the provider. The actual process of making a service from a service definition is up to a concrete implementation, which will be published separately. It is this implementation that for my use-case will pass the container instance to the definitions. The abstract factory knows nothing about the format of the definitions; only that they can be retrieved from the provider.

I hope this explains the problem better. But even if it does not, the service provider conceptually does not depend on container, because a container is not necessary to consume a service provider; it is necessary to consume the services provided by it.

Looking forward to your reply.

mecha commented 5 years ago

The psr/container dependency is indeed not used by this package. The psr/container package provides ContainerInterface and a couple of exception interfaces. None of those interfaces are referenced anywhere in this package's PHP code, only in inline method documentation. Therefore, it is not a dependency.

mindplay-dk commented 9 months ago

I'm closing this issue, as ContainerInterface is a dependency in the current proposal - at least for IDE support, and may become a a dependency for type-checking if #54 pans out.