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