Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120734 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18937 invoked from network); 3 Jul 2023 11:50:51 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Jul 2023 11:50:51 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 243CA1804BC for ; Mon, 3 Jul 2023 04:50:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_05,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS16276 192.99.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from mail.processus.org (ns563681.ip-192-99-44.net [192.99.44.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 3 Jul 2023 04:50:49 -0700 (PDT) Message-ID: Authentication-Results: mail.processus.org; auth=pass smtp.mailfrom=pierre-php@processus.org Date: Mon, 3 Jul 2023 13:50:41 +0200 MIME-Version: 1.0 Content-Language: en-US To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: / Subject: Re: [PHP-DEV] [VOTE] Interface Default Methods From: pierre-php@processus.org (Pierre) Le 03/07/2023 à 13:32, Michał Marcin Brzuchalski a écrit : > I voted "yes", my personal use case waits for this feature. My use > case example: > > https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b > > 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 > > then the trait has to be attached to every class besides that it has to > exist which is an additional symbol here. > > Cheers, > Michał Marcin Brzuchalski Please everyone yes to this ! I use Symfony daily, and the SomethingAwareInterface / SomethingAwareTrait is very annoying, by having default method implementations on interfaces, it would remove the use of having traits at all. Everything would be much easier to read and write. LoggerAwareInterface would no longer require us to use LoggerAwareTrait on every class, etc... This is kind of sugar candy I'd really love. Best regards, -- Pierre