search

container-interop / service-provider

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

This RFC breaks the PSR-11 definition #52

Closed wolfy-j closed 9 months ago

wolfy-j commented 4 years ago

Hi,

the current form of PSR provides additional constrain on PSR-11 at this line:

  • A call to get on an entry defined in a service-provider MUST always return the same value.
  • The container MUST cache the result returned by the factory and return the cached entry.

However, PSR-11 specifies the following:

Two successive calls to get with the same identifier SHOULD return the same value. However, depending on the implementor design and/or user configuration, different values might be returned, so user SHOULD NOT rely on getting the same value on 2 successive calls.

We use the container as part of the request scope in the long-running applications, this means that get MIGHT return different values based on a current scope. For example:

$user = $this->container->get(User::class);

This PSR can provide a great value to the community, but it's unclear to me why does it even touch the PSR-11. It can live perfectly fine by locking the definition to Service Providers only without affecting the ContainerInterface.

mindplay-dk commented 9 months ago

This PSR can provide a great value to the community, but it's unclear to me why does it even touch the PSR-11. It can live perfectly fine by locking the definition to Service Providers only without affecting the ContainerInterface.

Agreed.

The current draft PSR makes no attempts to modify PSR-11.

Since this got 3 up votes, no down votes and no objections, I am closing this issue.