Le mer. 24 juil. 2024 à 16:05, Larry Garfield <la...@garfieldtech.com> a écrit :
> On Thu, Jul 18, 2024, at 7:12 AM, Nicolas Grekas wrote: > > >> Otherwise, I'm quite looking forward to this. > > > > 🤞 > > Another thought that occurred to me. Given how lightweight it *looks* to > be (may not actually be, but looks it), how much overhead would there be to > having a compiled DI container that is lazy by default? Just make > everything lazy with a fairly standard initializer or factory, unless a > specific case says you shouldn't. That way you can use optional > dependencies in a constructor pretty much at will with no overhead of > needing to create a chain of dependencies as a result. > > Would that be a bad idea for some reason, or would it actually work? > > (This doesn't really affect my vote, more just a thought that came up.) I see no blockers. I don't have numbers nor plan to play with this idea in the short term but that could be fun to try :) Eg the Symfony DI could be updated to leverage the new mechanism (I did it already with a previous version of the RFC) and we'd try running an app with all services defined as lazy by default. To Rob: proxying by interface can be implemented using regular code generation so it's not a blocker. Symfony does it already, and will continue to do it to cover the use case. Nicolas
