On Wed, Jul 24, 2024, at 16:02, Larry Garfield wrote: > 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.) > > --Larry Garfield >
I'm not convinced a DI container is possible at all with this implementation, see "surprising behaviors." When you are building a DI container, you usually have *absolutely no idea* what a user will return from a proxy. At most, you might know they are returning SomeInterface or SomeBaseClass, but the user might return MyFancyClass that implements the interface or base class, which isn't allowed via this implementation. The type must be exactly the same or a parent class: > the factory of a lazy proxy is allowed to return an instance of the same > class as the proxy, or of a parent class. > > Returning an instance of a sub-class is not allowed — Rob
