On 2/20/11 9:03 PM, Lukas Kahwe Smith wrote:
On 17.02.2011, at 21:56, Jordi Boggiano wrote:
On 17.02.2011 21:31, Kris Wallsmith wrote:
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.
For having experienced the WTF myself and having seen a few others
suffer it too, yes, I have to agree it'd be much easier if we could skip
this and only those that need/want to know will know.
Another approach Kris proposed on IRC was simply silently "fixing" the scope in
case none is defined explicitly.
Aka when injecting the request service into a controller and that controller
has no explicit scope set, it would be silently set to request.
This would have the benefit of keeping more services in the container scope,
which could help performance. However it would of course mean that these
controller instances must not do anything with their state that would prevent
them from working correctly if used multiple times over the course of a
request. Furthermore it makes it harder for developer to realize that they are
moving services to a narrower scope when they add a service.
Then again performance continuos developers should always explicitly configure
their scopes, which includes Symfony2 core and Bundle authors who want 3rd
parties to reuse their Bundles.
I think the current default scope is the one that will lead to less WTF
problems for the following reasons:
* A DIC manages global objects, for which you need only one instance.
* The default PHP paradigm is to have only one global scope, so people
will expect that their object stay the same whatever request/sub-request
they are in.
* Defining a service that need the request is pretty rare (cf. point 1).
As we don't want developers to understand scoping at first, they won't
define it. With the current behavior, you cannot mess up when not
defining the scope for a service that uses a Request, as you will have a
proper error message.
But if request is the default scope, and does not requires the request,
then there is nothing to help you understand why your service is
automagically different in a request and in a sub-request.
Kris suggestion is really all we want to avoid in Symfony2: magic.
Fabien
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
