On Tue, 11 Feb 2020 at 10:14, Nikita Popov <nikita....@gmail.com> wrote:
> I'd like to get some feedback on the idea implemented in > https://github.com/php/php-src/pull/5168. It provides an easy way to > implement decorates, by taking care of forwarding any methods you do not > want to override in a type-safe way. See the PR description for details. > Hi Nikita, I almost missed this thread because all the discussion has been happening off-list; for anyone else interested, please note that there's a whole discussion of the concept, not just the implementation, on the PR. I actually posted a similar idea a few months ago: https://externals.io/message/103353 One of the criticisms of my example syntax was that it required you to list the methods to delegate, which makes multiple delegates easier (you can't have a name conflict unless you write the name more than once), but large or frequently-changing targets unwieldy. The idea of using the property's interface type to generate the whitelist does feel a lot cleaner. The other criticism though was that it only helps for the methods you're completely delegating, not those you want to decorate in some way. It would be nice if there could also be some sugar for those, perhaps a limited form of AOP where you could intercept the return value of a delegated call? interface Bar { public function doSomething(int $a, string $b, Blob $c): string } class Foo implements Bar { public delegate Bar $bar; after delegate doSomething { return $return . ' of doom'; } } would de-sugar to: class Foo implements Bar { public Bar $bar; public function doSomething(int $a, string $b, Blob $c): string { $return = $this->bar->doSomething($a, $b, $c); return $return . ' of doom'; } } That would also cover the fluent interface case: after delegate setFoo { $this->delegated = $return; return $this; } Decorating what happens *before* the call would be trickier, because you need to assign names for the parameters, and by the time you've written out the whole signature, you might as well implement the method in full. Regards, -- Rowan Tommins [IMSoP]
