Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120775 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 77775 invoked from network); 11 Jul 2023 14:04:36 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Jul 2023 14:04:36 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3F3A11804F8 for ; Tue, 11 Jul 2023 07:04:36 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (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 ; Tue, 11 Jul 2023 07:04:35 -0700 (PDT) Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-2b700e85950so87944261fa.3 for ; Tue, 11 Jul 2023 07:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689084274; x=1691676274; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uFyyIROCC71V7oEi+6VbHs83vZOiRA8Ynj936m/ZZvU=; b=sM0JVW6bKT94r4JDElACK447R/LFR7B1XX5IPwMFptchP7Ir+d0JK1lybBWq9Pzmtc ojcsfSMwZJpweJLAx+SMa8QLNmy6AQ4OaD3GBBtkxsPHMXod+Ca/MYOlhyAM3vzqVO4a /BmTlHEgDHuNDtFNnVSc1XHTFZWdQsUdqsIdMEFCy2iRvkFWHsYyp+a+uZhOjcWX1H/S lPpaIU3HIt73VOao8LKu/uLba5O/xKdqcutEceMP6eazH3tE5MP7uMMVjVIhy/ipr8KY rgPra/a5izo3etTuzgO+drP+5AQ6R1zcIjvMpCHSH6+CyD0C24zDQ1faAmNvJjUvxSo5 svqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689084274; x=1691676274; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uFyyIROCC71V7oEi+6VbHs83vZOiRA8Ynj936m/ZZvU=; b=SlvAssgx19Hraz7MEl0FGGN59lvFl8BI5V8+UaZFR7eYb3PPv9T6mvfLgOhg45QB5i U8DKgG+Zxnmw35TevGXgDO/dvh9wbZLcPWnVL6GBhlOIusVl3YrBDkWJnvL3IRwnx6hi RgJG4aRfhABlo6wj93XIrC9mhVGkPlIw2XG69JuaiJiXcdWSVCxGSWdnqnGMEx8tHe8j qtmurBHRxWkl+DAZX7pduaFk3w8TDpVtZLmKVq4aIvkTX0TU6l2ls2leytAVbzR8w8ZD EM5Optzj5ZWUFyaqCj9GBaMXdfHvPH/RyWMUC5ql1wAYIzeV3j3p2TatbULzqOC15YwL xyRw== X-Gm-Message-State: ABy/qLbN4gquuOMdzgPx5fLzXANfiuyhRWNt+3+Gfv8WlStkNZSPUh3c nypgoOQ7Tbumwyquprnvg0a1j0WP/QY1cSKIPYfK5FF5lRc= X-Google-Smtp-Source: APBJJlGi026zpxxuE5fy3Ni/IR1xILMjR54Je9FBnciasJ2VwUIR0Kv1/mr9DmYVn6v2rTnORscHSIk5E+0CfdkBAoY= X-Received: by 2002:a2e:8784:0:b0:2b4:7f2e:a42d with SMTP id n4-20020a2e8784000000b002b47f2ea42dmr14102693lji.41.1689084273815; Tue, 11 Jul 2023 07:04:33 -0700 (PDT) MIME-Version: 1.0 References: <3a3e7781-c2b4-2880-8048-d19458ac287d@heigl.org> In-Reply-To: Date: Tue, 11 Jul 2023 16:04:21 +0200 Message-ID: To: =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?= Cc: Deleu , Andreas Heigl , internals@lists.php.net Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [VOTE] Interface Default Methods From: landers.robert@gmail.com (Robert Landers) > Not exactly, How you wanna solve by abstract class two interfaces > which can be implemented using let's say two traits - let's say > > interface Foo { > public function foo(): string; > } > trait HasFoo { > public function foo(): string { return 'foo'; } > } > interface Bar { > public function bar(): bool; > } > traitHasBar { > public function bar(): bool { return true; } > } > > Now I can need to implement Foo or Bar separately or together. > Using abstract class that would require 3 abstract classes: Foo, Bar, and FooWithBar. > With this RFC that would require just two interfaces with default methods. This seems like a software design issue, not a language issue... But 3 abstract classes vs. 2 interfaces + 2 traits seems like a better tradeoff if you're going to need the coupling anyway. It's more obvious that you want/require FooWithBar when you want it. If you're expecting these exact implementations, moving them to the interface makes it even more confusing. I want FooWithBar (iow, I want these exact implementations) I want Foo&Bar (iow, I don't care about the implementation) You can pass a FooWithBar to Foo&Bar, but you can't pass a Foo&Bar to a FooWithBar. If the default implementation is on the interface ... who knows what you have, you'll have to check you /vendor folder.