Damn .. Johannes just reminded me that this is probably not possible technically.
On 17.02.2011, at 20:22, Lukas Kahwe Smith wrote: > 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 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
