Let's discuss, but my initial reaction is positive. There should be a firewall between requests to avoid unexpected behavior when upgrading from HttpCache to Varnish. In this sense, it makes sense for container scope to be the exception, not the default. The ease of use for beginners that you mention is also a strong pro.
k -- Kris Wallsmith | Release Manager [email protected] Portland, Oregon USA http://twitter.com/kriswallsmith On Feb 17, 2011, at 12:16 PM, Lukas Kahwe Smith wrote: > 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 -- 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
