I will also not work for not previously frozen container, as the applyInterfaceInjectors method call is called last. Any "per-method" injection disabling won't work in that case I'm +1 on disabling II for the whole definition as we can then achieve consistent results for both container types
On Thu, Apr 14, 2011 at 10:55 AM, Lukas Kahwe Smith <[email protected]>wrote: > > On 14.04.2011, at 13:46, Fabien Potencier wrote: > > > > > On 4/14/11 1:25 PM, Johannes wrote: > >> Just want to add some more options here which I mentioned on the > >> respective pull requests already: > >> > >> 5) Disabling interface injection on a per-method basis: > >> foo: > >> disable_interface_injection: > >> setContainer: true > >> > >> 6) Prepending calls from interface injection instead of appending them > >> > >> 7) Making it easier to disable interface injection globally > >> $passConfig->disableInterfaceInjectionPass() > >> > >> IMO 6) is easiest to implement, and is consistent with what we already > >> do for definition inheritance. > > > > all options except 6 seems overcomplicated to me. > > > it will still lead to stuff like: > > // interface injection > $instance->setContainer($this); > // override interface injection > $instance->setContainer($this->get('liip_hello.container')); > > For this specific use case it would fix my issue: aka I can then override > the service container with another call, but its obviously very inefficient > for a case > > // interface injection > > $instance->setFoo($this->get('super_expensive_to_load_only_used_here_service')); > // override interface injection > $instance->setFoo($this->get('some_other_service')); > > Worse it can break stuff > > // interface injection > $instance->addFooToStack($this->get('foo')); > $instance->addFooToStack($this->get('bar')); > // override interface injection > $instance->addFooToStack($this->get('my_foo')); > $instance->addFooToStack($this->get('my_bar')); > > So in conclusion: > Option 6) doesnt work. > > If you want simple then we must go with > https://github.com/symfony/symfony/pull/547 > > 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 > -- *Bulat Shakirzyanov* | Software Alchemist *a: *about.me/avalanche123 *e:* [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
