Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120645 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 70081 invoked from network); 20 Jun 2023 12:29:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 Jun 2023 12:29:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C10ED1804C9 for ; Tue, 20 Jun 2023 05:29:00 -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_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, 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-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (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, 20 Jun 2023 05:29:00 -0700 (PDT) Received: by mail-oi1-f172.google.com with SMTP id 5614622812f47-392116ae103so3125535b6e.0 for ; Tue, 20 Jun 2023 05:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687264139; x=1689856139; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=APP3Z2KmR+7d9TZk7NEiB+rEultG8RVpVArvncZcR9w=; b=mxOyAgIS2+7rrYeOjdIJsm/fVcnoQ0D7mj5SUAVDwXqVjiw28s9LBAAZEEM4jQeGkF ZUDTysaSISyHzoZHDzzZ/4RjSCWyF1fxrKg4uKYVmXwzufX7Ar9LZP1wb5G3FYweqK9u iSwqcakL/BEDINJFoar+GYIqr1SXjQQjyY9sX0SPPsLsAYmKV78HORE/14RDjR1EjxDA U7QTggYqb4ygLqCIklN4F2HgDB7TmobydONBOHztwfPv0csU+/178Won+FMsgCZu00zQ kExnEqANRZBezds//vRKzaPJ1WDAnsmOTJJlwZaruO/SIaRsUM8htS//yBwJwCL5tFlE cvTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687264139; x=1689856139; h=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=APP3Z2KmR+7d9TZk7NEiB+rEultG8RVpVArvncZcR9w=; b=DQzRim8FWWYlPYOiU30lnQXIDKaTPdKGqFGkyd88oeEROaRDZztgeIy5G0YuI4XWFq 6I3zbEq/pWL8gVXUqngecZNWGhKIE1S0gWIoestllPK+LyKynWl2JU774o9praVoWriW 4tt+L+My50pNlaukxiiKkunhs1/0rPQs4GSIiSYm6jlt0W1FPHsPEkj/j2hz0PhYKqhL tYJt/ri6DYGTeE45zv1m6nD7HCHSa+hQpdi4vzTbMLm7ahnLMjgy4PrmMizWQuMGGTJ2 f6ilDtoiLQbMmTqqJIX2TKM1GhiRkbnXNUx4+qstjLSl1zP7l6rnp3e3XOuNoFdE1QoX vrtg== X-Gm-Message-State: AC+VfDwFRBa31UpqLsoMK1SkRzNaa8WBHpBrikm9wh2JBcSeCyFO58Fx xNu4mFlkMYCG4yjbjtr4STps4fKlaMraFSfHNc8QcHVQ X-Google-Smtp-Source: ACHHUZ5F+jC9+vitLjmybw4UagEZMhpE6qWqAGt+jAgyuCiEfRXW7we/SjkiqJ3u1QeRw/xdwPF4NPCtGBjSMVGIO8M= X-Received: by 2002:aca:2813:0:b0:39f:545b:a8e5 with SMTP id 19-20020aca2813000000b0039f545ba8e5mr3790289oix.19.1687264139412; Tue, 20 Jun 2023 05:28:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 20 Jun 2023 13:28:47 +0100 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000ac109005fe8ecb7b" Subject: Re: [PHP-DEV] [RFC] Interface Default Methods From: davidgebler@gmail.com (David Gebler) --000000000000ac109005fe8ecb7b Content-Type: text/plain; charset="UTF-8" On Tue, 20 Jun 2023, 04:10 Levi Morrison, wrote: > > I like the idea of this RFC - in fact it's one which has been near top of > > my wishlist for PHP language features for a long time - but I think this > is > > an issue with the proposed implementation which at the very least > warrants > > highlighting and discussion. > > I understand your concern but personally believe it's overblown. This > problem already exists with abstract classes, but doesn't seem to be > that much of an issue in practice. I hope static analysis can fill the > gap here, but don't think these checks are necessary to ship this > feature. > Yeah I suppose I'm just saying "Interface default methods" can be interpreted a few different ways and there's key differences between Java-style, versus syntax sugar for mixing an interface and a trait in to one unit, versus a user can effectively extend multiple abstract classes but with interface keyword. Appreciate it appears to still be a WIP and you may not have decided or designed all the finer details yet but I think at the very least, the RFC text needs to be updated as soon as practical to be much more explicit about these details so voters know exactly what they're voting on when the time comes. Cheers. > --000000000000ac109005fe8ecb7b--