On Wed, Jul 24, 2024, at 16:13, Rob Landers wrote:
> 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
Sorry, misspoke:
> what a user will return from a proxy.
should be "what a user will return from a factory."
— Rob