Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120582 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 98651 invoked from network); 15 Jun 2023 03:47:58 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Jun 2023 03:47:58 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 539FA180340 for ; Wed, 14 Jun 2023 20:47:54 -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,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE,T_SPF_TEMPERROR 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-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 14 Jun 2023 20:47:53 -0700 (PDT) Received: by mail-wr1-f68.google.com with SMTP id ffacd0b85a97d-30fcde6a73cso2088642f8f.2 for ; Wed, 14 Jun 2023 20:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datadoghq.com; s=google; t=1686800872; x=1689392872; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=fRAUxXmBt9kHhyrpMpdXZMJwxypLq8agvnwdZAMHgNA=; b=ht7HNQtNhWvjwNDEPMJSxi4NiMEVx8dltLWS6jJsiAyCkV+IyhmcGXTgCDjObcsAd/ VjDfSDabL78yJx3w14+bB0t7yiA+VgAPCE+7g1ESKonPvdFm7tS81s6g8wwDYQJQXgBR nqx45+stuBr4pFwGHHHEZjZIm5x93q35SUZTA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686800872; x=1689392872; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fRAUxXmBt9kHhyrpMpdXZMJwxypLq8agvnwdZAMHgNA=; b=Bn857C8jQAc5BDHoiasL/UhRWGVGn6r3RpT0vw4gq6mjYxmxlRFeSvmLqz/qpcyO0f JPROrIQjHH1eOwN/RGogCvAcpkcVXpb8ClWm8s9QvcHj84OHluF3K+yfUnIciyIjoiK+ Foexz9ncOIjP4vWTZO6xGq0x2Dtq1Nlw5e9PRhi3EEDWanIC2vpxdwSGujm7swcPHbRX xOv660ScR/zrhegtbs/uZaaNbAbVDvMS9rXhG5XW6EOgyDlBcJg7ligVFx9tALU1Ixv/ KRlulZ5gqfZrwDV1A+iIjjI9Vt3v/gp736uoxZux7+dcvRBqyNP+JKESVbrLTLIZCCdk BrEg== X-Gm-Message-State: AC+VfDw+nkACni+DhXRm7ckuA6Y9gyw2XpvOmMo8EnDR8hVDwnFqofik eRqxZOk5X/f1IFUP1P38sd/aYqdd8PmHB3/59NBSNKbUYx7be2sD7+tLka24ndc= X-Google-Smtp-Source: ACHHUZ5o/wpVdTadn6fcn66ccbsBEUiWF6QIXzamlk1WSa7+583Rdycug3mJ5OElBlfFxKT0NA2SyBd8gxfPOFKsgQc= X-Received: by 2002:a5d:4903:0:b0:30d:d85c:4472 with SMTP id x3-20020a5d4903000000b0030dd85c4472mr9103945wrq.62.1686800871863; Wed, 14 Jun 2023 20:47:51 -0700 (PDT) MIME-Version: 1.0 Reply-To: Levi Morrison Date: Wed, 14 Jun 2023 21:47:40 -0600 Message-ID: To: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: [RFC] Interface Default Methods From: internals@lists.php.net ("Levi Morrison via internals") Hello, PHP Internals, I am moving my RFC for interface default methods to discussion: https://wiki.php.net/rfc/interface-default-methods. This can be a useful tool for a few reasons: 1. It can make implementing an interface easier when certain methods can be implemented by other methods in the interface. For example, if `Countable` had an `isEmpty(): bool` method, it could be implemented by doing `$this->count() > 0`. Of course, if an implementation can be more efficient, they are still free to implement it how they want. 2. It can mitigate BC breaks in some cases. It's somewhat common for authors to want to expand new methods onto existing interfaces over time. Although this would still be a BC break, it moves it from a massive change (every single implementor must add something, even if it's a stub, or it will fail to compile) to a naming collision issue only (only classes which already had a method of the same name will fail to compile). There is prior art for this feature in both Java and C#. There may be other languages, but I was aware of at least these. Note that the RFC links to a partial implementation. If there are two or more interfaces with default methods of the same shape (name, args, etc) and a class implements both interfaces and doesn't provide a concrete implementation, which default implementation should be chosen? There is a proposal for resolving this in some cases which is modelled after Java's implementation, but it isn't implemented. Thank you for your time. I look forward to productive feedback. Levi Morrison