Hi, In the RFC you imply that the common case is that dependencies will not be used. I think the common case we should expect is that all dependencies will be used. The rare situations that I see in my current work is stuff like mailer or in some cases handles to external data sources which might be made superfluous due to caching. The caching case can only really be handled by injecting the service container I guess.
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. Approach 5: I do not have experience with annotations, they do have some appeal and I can see improved support for them in future PHP versions, but I also agree that its a bit tricky to start defining sort of our own phpdoc language. Not really the way to go to make symfony easier to learn. 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. 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. 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.
