On 21.03.2010, at 11:20, Lukas Kahwe Smith <[email protected]> wrote:
A problem that arises here is that you can break existing actions
by defining a new service with a request parameter name.
The only solution that comes in my mind is to force type hints for
services...
but what exactly do you want to type hint? you would need a one to
one mapping between an interface and a service name.
ok. just thinking out loud here. i dont have a final proposal here. i
guess if we go the hybrid approach. that is all non optional
dependencies and non object dependencies are injected into the
constructor then we would only be injecting optional class instances
and all the other parameters that would normally be injected would be
non objects. now if you do go to the trouble of extending the class
you want to inject so that you can type hint that name then one could
alias service instances right inside the action method by writing the
service name as a type hint along with any variable name that doesnt
overlap with a expected request parameter.
we could also just say anything with a type hint that collides with a
request parameter name overloads the request parameter. in that way we
would no longer care about what is written as the type hint only that
there was a type hint. of course if php ever gets scalar type hints
one would have to filter those out again. what happens if php ever
gets a string class to handle unicode and suddenly a request parameter
could be an instance of that and worse yet of some extended version?
the first type hint approach sounds somewhat feasible since its really
just for optional dependencies which should really be needed very
rarely which means here it might be ok to force extending just to be
able to use the type hint magic. the second just sounds like a world
of hurt bound to happen.
regards
Lukas
--
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
To unsubscribe from this group, send email to symfony-devs+unsubscribegooglegroups.com or
reply to this email with the words "REMOVE ME" as the subject.
