Re: [VOTE] Interface Default Methods

Hey Michał On 03.07.23 13:32, Michał Marcin Brzuchalski wrote:

Hi Levi, pon., 3 lip 2023 o 02:11 Levi Morrison <morrison.levi@gmail.com> napisał(a):

Chatter on the [Interface Default Methods RFC][1] has been quiet for the past 6 days, and the feature freeze deadline is fast approaching for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks as usual. Thanks to everyone who discussed weaknesses in the RFC during the discussion phase. [1]: https://wiki.php.net/rfc/interface-default-methods

I voted "yes", my personal use case waits for this feature. My use case example: https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b

I've added two already possible solutions to that as comments.

With interface default methods I'd no longer need traits that implement a single or in rare cases 2 methods that use their respective methods returning objects and iterate in Generator fashion over a paginated result set. This is not an issue if there is one implementation of the interface but when I decorate to apply some: * caching * logging * failover

That requires that you are in control over both the interface AND the implementation. In which case you probably do not need an interface and the Trait would be enough (using abstract public function in traits works after all) So you could even skip the implements part. As the interface should be designed specifically to be implementation-agnostic, adding implementation to the interface is counter-productive. Adding abstract methods to a trait and then just adding the traits is no issue at all especially when you are in control of the interface AND the implementation. When you are NOT in control of the interface... well, you can't expect to have a default implementation and I am already looking forward to the complaints that it is great to have a default implementation, but not *that* one. There is a reason why the respective construct in Rust (which was mentioned in the RFC) is called a Trait and not an Interface. So to decouple the contract from the implementation it is necessary that no implementation is part of the contract.

then the trait has to be attached to every class besides that it has to exist which is an additional symbol here.

Stop using implements at all and solely rely on use. My 0.02€ Cheers Andreas -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +---------------------------------------------------------------------+

Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc