Just to add here, the idea of determine the scope automatically fails as soon as someone injects the container and then starts reading out request service data into properties. For a user to understand what they are doing "wrong" here, they already need to understand scoping, which brings me back to the point to defaulting to scope "request".
As for automatically injecting request, I am not so much a fan of that, but still it might be worthwhile to explore to prevent the current beginner very unfriendly situation. On 22.02.2011, at 20:58, Bulat Shakirzyanov wrote: > Maybe we should pass the request to the action directly then? Fabien? > > On Tue, Feb 22, 2011 at 2:57 PM, Lukas Kahwe Smith <[email protected]> > wrote: > > On 22.02.2011, at 20:51, Bulat Shakirzyanov wrote: > > > Please don't use term "premature optimization" here > > > > "Premature optimization" is a phrase used to describe a situation where a > > programmer lets performance considerations affect the design of a piece of > > code. This can result in a design that is not as clean as it could have > > been or code that is incorrect, because the code is complicated by the > > optimization and the programmer is distracted by optimizing. > > Well imho the code is more complex if we keep the default at scope at > container, because it requires people to understand scoping where they > otherwise would do fine without, just with potential performance penalty. > > > I think a proper fix would be to remove Request from service container, > > letting users only get ahold of it in an event listener, which is not > > request instance bound. And also document this as the recommended way of > > operating on Request. > > Not sure I understand, there are still lots of uses for injecting the > request, not the least of which is reading GET and POST parameters. > > 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 > > > > -- > Bulat Shakirzyanov | Software Alchemist > > a: about.me/avalanche123 > e: [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
