Re: [Pre RFC] Automated delegation using implements by

Am 01.10.2026 um 02:29 schrieb Karoly Negyesi:

I submitted a draft RFC to https://github.com/php/php-src/pull/24030 <https://github.com/php/php-src/pull/24030>. The PR contains an implementation and tests (please be gentle, I haven't written C in decades). I propose an "implements by" syntax to automate delegation, closely modelled on Kotlin. In short, interface T { function foo(); } class A implements T { function foo() { print "A"; } } class C implements T by $t { function __construct(private T $t) {} } new C(new A)->foo();

The RFC motivates this feature with "unnecessary boilerplate and maintenance burden as the interface gets more methods over time". I think this premise is flawed: an interface that keeps gaining methods over time usually violates the Interface Segregation Principle. The remedy for that is smaller, more focused interfaces, not language support that makes delegating to ever-growing interfaces cheaper. There is also a correctness concern: with generated forwarding, a method that is later added to the interface is silently delegated by every class that uses "implements ... by". In the RFC's own example, a new URL-generating method would be forwarded without the metadata bubbling that MetadataBubblingUrlGenerator exists for. Today, such a change forces the author of the decorator to make a conscious decision. I am also not convinced that any benefit this may have outweighs its downsides: it adds new syntax that static analysis tools need to learn about, and it adds complexity to the compiler. The "To the Ecosystem" section currently only lists "Less boilerplate"; it should account for these costs as well. -- Sebastian Bergmann https://phpunit.expert Stay up to date with PHPUnit: https://phpunit.expert/newsletter