On 22.03.2010, at 13:18, Fabien Potencier wrote: > On 3/22/10 1:09 PM, Lukas Kahwe Smith wrote: >> Approach 3: >> I think approach 3 has the least merit. It defaults to a lot of magic and is >> going to be quite unreadable. I also do not understand why you say that "All >> the magic is optional."? It also doesnt feel like "Very concise code;" to >> me. Sure you do not need the boilerplate code in the constructor, however >> you need to repeat the same parameters in all your action methods for all >> the share dependencies. > > The magic is optional as you are not forced to pass any service in your > methods. You are right about conciseness. The method code is more concise, > but the method signature is not anymore.
Hmm, how is it optional? With approach 3 you do not have another way to inject, unless you are referring to injecting the service container, which still means that there is no way around any kind of magic. >> Approach 1: >> I do not like approach 1 because of the circular references and the fact >> that its not so easy to see the dependencies by just looking at the >> constructor (and action method) signatures. > > Which circular reference? I don't see any. Isnt the controller also handled by the service container? >> Approach 2/4 >> As such I like approach 2 and 4 the best. For approach 4 I would encourage a >> postfix for services. It can even be something long like "Service". This >> indirectly encourages people to prefer injecting into the constructor, which >> imho is the better approach. Once we have traits (I am very certain we will >> see this in the next bigger version of PHP), we might be able to provide a >> trait to reduce the boiler plate code. > > A Service postfix for services sounds good to me. But then, I think we need > to be consistent and add the postfix for both services injected in the > constructor and those injected in the methods. Well ... my point was that a postfix, especially a long one, makes it abundantly clear which one is the preferred method. Plus I do not think its all that inconsistent. There are no collisions possible in the constructor, but there are in the method signature. -- Of course we could also just not inject the route parameters so that we do not have naming collisions if we go with approach 3 or 4. But I would find that quite unfortunate. 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 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.
