The complete removal of it is rather unfortunate. I can only speak for OpenSky's code base, but we've relied on it for our controller services. Having our controllers implement things like RouterAwareInterface, SecurityContextAwareInterface, and the like (all things that the base, non-service controller class depends on), allowed us to embrace DRY and avoid:
- Many, many constructor arguments - Many <call> blocks for setter methods Without interface injection, the configuration for controller services is going to become rather hellish (at least for very large projects). It's late in the Symfony2 development lifecycle and I admittedly have not closely followed the argument here, but are there no solutions to be found in Spring's or Google Guice's implementation of interface injection? On Tue, Apr 19, 2011 at 4:51 PM, Fabien Potencier < [email protected]> wrote: > After a short discussion with Bulat, I propose to remove interface > injection from the DIC altogether. The added benefit is quite small and > it's not easy to make it for edge cases like the one exposed by Lukas. > So, instead of adding even more complexity to a very small feature, > let's remove it altogether. > > Fabien > > -- > > Fabien Potencier > Sensio CEO - Symfony lead developer > sensiolabs.com | symfony.com | fabien.potencier.org > Tél: +33 1 40 99 80 80 > > > On 4/17/11 4:39 PM, Bulat Shakirzyanov wrote: > >> Good idea but it won't work with not frozen containers >> >> Sent from my Nexus One >> >> On Apr 17, 2011 10:23 AM, "Jordi Boggiano" <[email protected] >> <mailto:[email protected]>> wrote: >> > On 17.04.2011 15:59, Lukas Kahwe Smith wrote: >> >> No, I do not want to disable injection for an entire interface. >> >> All I want is to be able to decide on a per service basis what to >> inject without syntax sugar features from limiting me. >> >> At the same time I do not think it makes sense to add a bazillion >> new flags and options to handle disabling these syntax sugar features if >> they cause a problem. >> >> >> >> This is why I (and I guess also Bulat) favors the simplicity of a >> per service flag (rather than a per method/interface flag etc). >> >> >> >> So yes, the point isn't that I want to just blindly disable all >> interface injection for a service, but that I think trying to do it more >> granular is overboard and for the few (but important) cases where I run >> into issues with interface injection I am prepared to manually deal with >> it by then manually setting the proper services to call. >> > >> > +1 on this >> > >> > Another approach though, which might conciliate everyone (riiight): >> > >> > services: >> > foo: >> > class: lala >> > interfaces: >> > Some\Interface: @otherservice >> > >> > Basically there you could override which services are taken for which >> > interface, on a per-service basis. >> > >> > Cheers >> > >> > -- >> > Jordi Boggiano >> > @seldaek :: http://seld.be/ >> > >> > -- >> > If you want to report a vulnerability issue on symfony, please send >> it to security at symfony-project.com <http://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] >> <mailto:[email protected]> >> >> > To unsubscribe from this group, send email to >> > [email protected] >> <mailto:symfony-devs%[email protected]> >> >> > For more options, visit this group at >> > http://groups.google.com/group/symfony-devs?hl=en >> >> -- >> 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 >> > > -- > 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 > -- jeremy mikola -- 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
