On Wed, Jul 24, 2024, at 22:45, Nicolas Grekas wrote:
>
>
> Le mer. 24 juil. 2024 à 21:44, Rob Landers <rob@bottled.codes> a écrit :
>> __
>>
>>
>> On Wed, Jul 24, 2024, at 16:28, Nicolas Grekas wrote:
>>>
>>> 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.
>>
>> I'm not sure what you mean, as the RFC makes it look this should be
>> completely legal, until you get to the end:
>>
>> interface Fancy {
>> function sayHi(): void;
>> }
>> class A implements Fancy {
>> function sayHi(): void { echo "hi!"; }
>> }
>>
>> $container->register(proxyType: Fancy::class, factory: fn() => new A());
>>
>> // Now container only knows that it needs to return a FancyClass and this is
>> "legal looking":
>>
>> $lazy = new ReflectionClass($proxyType)->newLazyProxy($factory);
>> // same as
>> $lazy = new ReflectionClass(Fancy::class)->newLazyProxy(fn() => new A());
>>
>> This ^ compiles, it's perfectly legal and makes 100% sense that I should be
>> able to call $lazy->sayHi() and it calls A::sayHi(), which is what you would
>> expect. Instead, this is runtime error.
>
> The reason why this doesn't work is that the RFC is about state proxies,
> which means properties are required to hook the lazy behavior.
> The RFC forbids your snippet because the initializer must return a parent of
> Fancy::class, which A::class isn't.
>
> Please have a closer read of the RFC, we tried to describe the reasoning as
> much as possible and this is covered.
>
> Nicolas
>
My point was that this can’t be used for any DI container on the planet (unless
you parse the code and statically figure out what concrete type is returned —
hope it is only one type — and will only work for the simplest of cases). There
is nothing here that can be used for DI unless people are injecting concrete
types and not using inheritance, which goes against the “code to the interface”
rule we’ve been using for the last 20-40 years…
— Rob
