@nicolas-grekas thanks for this PR and for your other proposals to improve the DI component.

Given that this kind of concepts are a bit abstract, it'd be nice if you displayed a very simple before/after comparison code sample showing the benefits. Thanks!

@nicolas-grekas im curious.. why would one choose getter overriding over setter/constructor injection?

It's really cool.. but it allows to bypass traditional service definitions like;

dep:class:...lazy:trueservice:class:Servicearguments:['@dep']

with

service:class:Servicegetters:getDep:'@dep'

and creating classes like

class Service {publicfunctiongetDep() {}// stub}

edit: i see the benfit for being lazy though :/

edit: i see the benfit for being lazy though :/

then you have your answer :) see the linked issue for more.

Figured it out. But still.. why make the service a proxy, when we already can proxy the dependency itself (lazy: true).

As said in the linked issuelazy: true has no effect when ocramius/proxy-manager is not installed.
Which means it's a userland only feature, we can't rely on it in the core.

Ok.. if that's the case i'd favor a core implementation oflazy: true. Personally i have no problems with a package less or more.

I think i'd stick with lazy dependencies, opposed to lazy services. It feels weird to do a different approach only to save on a package...

I was just answering to your question, but there are more arguments. Please read the linked issue.

Implementation is ready, generated code looks good.
Note that the anonymous proxy classes need a property or two, whose name shouldn't collide with any existing properties in the service class.
I chose a1337 5|*34|< strategy, naming those:private $c0nt41n3r andprivate $g3ttErV4lu35;.
We could have a randomly generated suffix instead. WDYT?

Random would be more safe right? I'd go for that :)

@nicolas-grekas

What would be the list of things to do to bring the support of this functionality on PHP 5.6.X ?

@jean-pasqualini: we'd need to replace the anonymous inline classes by real classes, dumped in the same file as the container, just after it (as done for lazy-proxies right now by the addProxyClasses method). There is no major blocker I guess, just more time to spend, so maybe later, maybe by someone else than me :)

That means that classes written take advantage of that will be completely dependent on Symfony's container right?

@stof comments addressed

PR updated with@experimental mentions, as explained inhttp://symfony.com/blog/experimental-features
Ready to merge :)

Thank you@nicolas-grekas.

Surprised to see such controversial feature get merged. There were various critiques by people who are not in symfony core.

@flip111 it has been merged as anexperimental feature (it may be removed if we're not convinced by it). Anyway, as with all Symfony features, you don't have to use it if you don't like it.

Hello everyone.

I'm so sure that is too late, but anyway, I would like to expose my POV.

I'm sorry but...@nicolas-grekas what is that?
I mean, even if experimental... what is this new feature trying to solve?
Dependency Injection should be a component with the capability to solve and implements some patterns to allow people to expose their services into the framework. At least, I think that this was meant to be at the beginning.

DIC should be a layer to make our projects better. Are we agree about this?
The Symfony DIC started by adding some extra features, not helping us making better code (for example, allowing us to add dependencies in public parameters, or by adding setters), but the explanation of "We should help as much as possible new adopters to adapt their code to this new way of thinking" make me feel so good with that.

So... then what?
Do you (and when I say you I mean the core Symfony team) still remember what is the purpose of Symfony? Or the question should be... what is YOUR purpose of Symfony right now? Make a tool for everyone, in every situation and in every single kind of project?

It should be not.

Then... maybe is to provide a good RAD layer to new adopters? And do you think that these kind of features will help them to understand better the pattern and the project? Don't you think that these kind of features (like Autowiring, BTW) will only cause the effect of making new people understand in a bad way what the Dependency Injection is?

If your obsession is RAD, please, focus on real RAD

• Easier way of defining bundles
• Better code (by better code I mean better readable code)
• Better, bigger and stronger communities and events

Please, focus on what's important for all the Framework and components, and don't be obsessed on do more, and more, and more, even if is not important or it should not be part of the core... (this is why we have bundles, right?)

Reverted in#22158 now that we have other alternatives.

Note thatJMSDiExtraBundle provides getter injection since years:
http://jmsyst.com/bundles/JMSDiExtraBundle/master/usage#method-getter-injection

@nicolas-grekas: About what alternatives you're talking about? I'm fiddling around trying to find why this feature was reverted - blog post didn't mentioned that.