[DIC] Prototype scope: Injecting a prototype service into a normal service shouldn't require non-strict references #12585
Comments
|
I understand your concern; however, I'm not sure we can change this behavior as it has been changed very long ago (before the release of 2.0 actually.) Anyway, I truly believe that using prototypes in the service container is almost always a mistake; we don't have any example in Symfony core and everytime someone give an example, it's a wrong usage of prototypes (not sure if this is the case for your use case though.) I would even go as far as proposing to remove the prototype scope for 3.0. |
|
Using the prototype scope is an easy way of using the factory pattern in the DI container. Otherwise you end up with additional factory services that ONLY have one method: create(). Seems a bit silly, but I understand what kind of complexity it adds to the DI container. Although, not as nearly as much as having scopes in the first place. |
|
@rassilon for most factories, you would still need to create a separate one, because it is common to pass arguments to the factory. |
Using a prototype scope service from a container scope service shouldn't throw a 'Scope Crossing Injection detected' exception.
This appears to have occurred before 2.6 was released via 803dd58.
It does seem weird to me that prototype is even a special kind of scope. Symfony 1.0 DI called this shared: true/false. This is how I think DIC systems should treat non-shared services (that don't use factory patterns). Scopes should alter major service lifecycle events, and shared/non-shared is just how many instances the DIC ends up creating over the life of the scope.
Thoughts? The fix appears as simple as ignoring prototype scopes in the referenced service definition in CheckReferenceValidityPass:validateScope.
Thanks,
Bill
The text was updated successfully, but these errors were encountered: