Re: [RFC] Lazy Objects
| From: | Nicolas Grekas | Date: | Wed, 24 Jul 2024 14:28:01 +0000 |
| Subject: | Re: [RFC] Lazy Objects | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-124575@lists.php.net to get a copy of this message | ||
Le mer. 24 juil. 2024 à 16:05, Larry Garfield <larry@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