Aloha, So after a chat with Johannes its possible after all. It requires some changes, but rather small. Something we can safely do in Paris still. So now I am asking for agreement again.
On 17.02.2011, at 20:28, Lukas Kahwe Smith wrote: > 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 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
