Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120600 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84233 invoked from network); 15 Jun 2023 21:36:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Jun 2023 21:36:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 59DC11804A7 for ; Thu, 15 Jun 2023 14:36:45 -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-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (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 ; Thu, 15 Jun 2023 14:36:44 -0700 (PDT) Received: by mail-oi1-f171.google.com with SMTP id 5614622812f47-394c7ba4cb5so123730b6e.1 for ; Thu, 15 Jun 2023 14:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686865004; x=1689457004; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=t1fvHjbcpDFC7DsXgJHnWaqoFDGRFM4DvNWkzkPxejE=; b=Nui1FKZ4CQux0FCrxV/P66T1Um8Lqu3a1bkj+6/Glb3wFYV+nEZKca5aH+GEB18b6k al2MSsoEblxGtadyMF+lSHUOEyWDy1Z88kSNF8U+za2uefq9chw4sxTxmLP8ifKe338y pCPONnDzKBlD0C9A+sgzmIVT+y0gQQkSfvC4nrjzKf+PHkfQwb8mzO4Mh8gvQow0Swpr XwrOb132z37aEQjPcf2E2kB1wBHgvhvvXl7HOsXVhVWBcPhYTnUL11wS+L3/OJ6LOEdf RxhehGT8gQXAlQuoD33XXbx8D8MT/kIvowEqK655pDIk4DYMm7cuoHkBcN4SMooQH5un jB3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686865004; x=1689457004; 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=t1fvHjbcpDFC7DsXgJHnWaqoFDGRFM4DvNWkzkPxejE=; b=d+Agrsi2oLmM7TsO6e9dI3vnMz/DVnFAaMc5R9YXWzwKDAsf0Vxdwtk7b+db8YDcJh kItwNW2lx7eInRousrYbbupRqRpHguw9+j2ogPo5BCrFV3W9BmJFjiqY5hWgOtFN3baE 35Xta6REZNAkPtexzVDow0MO2vanhV2rLoS5K0735QYHXIjDHM9t+75p+2UnUpe9kIjL 2XzyeMZ20PoJdqj83ZhoBSjyjSpEB1gF9e1VkWXG/iiCFD8xI6h8uNl0IACSu+VogFGP pJlRqcKiw1FL+7SKY65kQqKzTjDnybMKYzjtZo1DcFUmfeHlSYD1IivUhHhbhzjrk9V/ Kz1Q== X-Gm-Message-State: AC+VfDwl1f+71p65ZJlcvRJsbFxjMCu0TpjrkWwHA34Z5jEilprjxV7+ lkkya2gELiO5WSdkjJ3ItZI47mWCdsktKAP/Yvv8x3R9Rhg= X-Google-Smtp-Source: ACHHUZ47k49pGQihIte3xX52RQNDJDRacOfpSXa0c5gcabE0mfwpHWK5p4nU4jP5w3P2WHbSc3oj3cRONP1CkxSo7IM= X-Received: by 2002:a05:6808:2396:b0:398:6008:f460 with SMTP id bp22-20020a056808239600b003986008f460mr487965oib.28.1686865003861; Thu, 15 Jun 2023 14:36:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 15 Jun 2023 23:36:32 +0200 Message-ID: To: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC] Interface Default Methods From: tovilo.ilija@gmail.com (Ilija Tovilo) Hi Levi > I am moving my RFC for interface default methods to discussion: > https://wiki.php.net/rfc/interface-default-methods. This or a similar concept makes sense to me. The proposal seems similar to Swift protocol extensions, or Rust traits, with the exception that function default implementations may only be defined in the interface itself. Note that there's a large overlap between this proposal and extending traits to allow implementing interfaces. https://wiki.php.net/rfc/traits-with-interfaces The main difference is how you would use the feature from a given class, i.e. using an interface implementation or a trait usage. Implementing interfaces from traits would require declaring both a trait and an interface. I do think your proposal is the more natural approach. The redundancy of interfaces and traits after this RFC are also somewhat unfortunate. Both interfaces and traits could inject default behavior into classes. Both could enforce implementation of methods in classes (traits through abstract methods). My intuition is that interface default implementations should be used for public APIs (because this provides an abstracted interface), while traits should be used for protected/private ones (because non-public methods can't be added to interfaces). The other obvious difference is that interfaces don't allow manual conflict resolution while traits do. The RFC doesn't mention default implementations for static methods. I'm not sure there's a use case but it might make sense to explicitly mention whether they are supported. Ilija