Hi, I want to propose to change the default scope from "container" to "request". This has many reason the main one being more beginner friendly, especially since DI scope is a pretty advanced topic, which I am sure most people don't know about.
So let me explain it briefly: In the beginning we had "shared" which could be true (old default) for services that should be instantiated only once for the given container instance. Then there was "shared" false which meant that every time the service is requested a new instance should be created. Now Johannes and Kris introduced scope, which basically changed things as followed: shared: true => scope: container shared: false => scope: prototype They also introduced scope: request, which is a special scope. Basically when ever one enters a (sub)request any service of request scope that was previously instantiated is moved to a safe location. But for that (sub)request its like the service was never previously instantiated. The first time the service is requested within the (sub)request therefore a new instance will be created, but that new instance will be reused through out that specific (sub)request. Now when returning to the previous (sub)request, the old instances are stored and available again. The request service has the scope request for this reason, as it need to "change" within every (sub)request. Every service that injects other services obviously is not allowed to have a "wider" scope. So you cannot inject a service with scope request/prototype into a service with scope container etc. So now lets get back to my proposal. To make it clear I am not talking about changing the scope of any of the internal services. So I am proposing that any service that currently does not have an explicit scope set, should be set to "container" (the current default) and that we then change the default scope for any service that doesnt explicitly set a scope to "request". The benefit is: - beginners would not face having to understand scoping when they inject the request service for the first time - most php developers are not used to being worried about state in their php objects, as a result if their services do store some request specific state and they do not set the state to request, they will have really hard to debug issues when they have subrequests. note I do not believe that this is the common case, but common enough with a big enough wtf factor so that it would be good to avoid this The drawbacks: - a bit of CPU/memory overhead if a service that should be scope container is instead scope request Looking at the pro's and con's I believe that being beginner friendly and less wtf issues outweigh's the con's. Especially since the con implies a lack of understanding of the scoping concept, which would mean that the developer in question would severely suffer if this change would not be made. regards, Lukas Kahwe Smith [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
