Don't forget about not frozen container builder, it will not worth the granularity there On Apr 17, 2011 10:00 AM, "Lukas Kahwe Smith" <[email protected]> wrote: > > On 17.04.2011, at 15:45, Johannes Schmitt wrote: > >> Can you explain why you would want to disable interface injection for an entire service? >> >> The use cases I see are that you want to disable injection for an entire interface, e.g. for ContainerAwareInterface, or that you want to disable injection for an interface for a specific service (e.g. generally you want injection through the interface to happen, but for one specific service you want to inject a different dependency). >> >> I just can't make something up for disabling injection for all interfaces that a service has implemented. > > 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. > >> My vote still goes for solution 6). Also keep in mind that if we add another flag, then we also need to think about how that is inherited, e.g. if another definition inherits from a definition which has interface injection turned off, is it now also turned off for the entire child service? This would be a big limitation. > > Are you just ignoring the issues I mentioned for 6)? > Obviously for inheritance it would also apply to the inheriting service, unless the inheriting service would flip the setting. > > 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
-- 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
