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
