Hi,
I may miss something, but why just ignoring the parameter name and
focusing on the type hint to avoid conflicts ?
function showAction(UserService $myUserService, MailerService
$thisIsTheMailer, $user, $pi = 3.14)
{
$myUserService->setAttribute('name', $user);
}
We don't care about how we call the UserService parameter and we let
the magic passing the right service base on type hind.
No conflicts, no comments to analyse and we have a good integration
with IDE auto-completion capabilities.
What do you thing ?
On Mar 21, 11:44 am, Lukas Kahwe Smith <[email protected]> wrote:
> 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.
