Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118397 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 64449 invoked from network); 10 Aug 2022 13:26:56 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Aug 2022 13:26:56 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DA9C51804BC for ; Wed, 10 Aug 2022 08:28:44 -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,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) (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, 10 Aug 2022 08:28:44 -0700 (PDT) Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-10ea7d8fbf7so18170304fac.7 for ; Wed, 10 Aug 2022 08:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=bZNLvw+Ojq4OydSRJ9E+vkZObaJe3TF4M+G/VxjYKPE=; b=CrNOjka2b2w+EBPvdc1qFFBUG/ZTAHaBECtxGj13UYAMxmNKQXr/1zgCDR9ER6Pe4f ZfC6f1GeXZR6xv4EtWC1jXt/7n3XA/i6IsT3sFBSJYUmChLUvePcvtP+W8OyHfgpk+GY ETEJQKw429Fikap+fdi8pAzyboa3LhrnBI6NL3UODvCjRMrnWMWiZM/sBAHF1yHmUwx4 NfgRQ9n5X229DsnoGEsveEqERa4TFfX8AuZA9ict/RVpzgq4Tifohtkmo2w+zpy1Ub8A rvGvKkXpnEtenlPfGqVxv/vmECaMzW4dC3qeDFZr1viC5sK0pwnu0OyMOmb0Roc0T8Yc KUWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=bZNLvw+Ojq4OydSRJ9E+vkZObaJe3TF4M+G/VxjYKPE=; b=gchXh0LVZrfCHIH8OX7jk1ODa+z76OGNdop4x0hp3ktq98Ro8PWBC3xX0yOA4HhWI1 JeiSHRAr6OaIHfxxjwg5g1rqJW1i15cHK+Ap5IEQGkhSHRDh9TaTHzWTyqPm1x1uOtBk x7nB9AEeqM4VJsasrgpAcOwBNQ270+Z5vNJeboPcOK/6e/Hrv4wYtGDigeyvy/ibS7ZM lIInR16oF3ltdaESQagvN5gxpvTA5dBGGoi35TyyBaKKmipW7XtlWjdl4TmFIMLtsQqQ N5gy9Lp3l4tzMrgJwxQ7wBH3mFcA8a+u0MWXT682mOpYo0nnP88APtjdiWVrXDxibMEs IXUw== X-Gm-Message-State: ACgBeo0cbRbPHE1huLdn6NdSvc7rhr4Kicb9zV1GCnth6CSdg+9l6NxR HFKud8CN3An8faWf0CMftmZY42JRxcrWfrVAF+k= X-Google-Smtp-Source: AA6agR4+DS0HRP3l2HkF+6wew2AtA+/OFO5WjOd4BsFWRaeWs/CQaHCPO+Zw3rMivHvFmazGWRNum9NoJebg9t3TdP0= X-Received: by 2002:a05:6870:51cb:b0:fb:5c97:bd1b with SMTP id b11-20020a05687051cb00b000fb5c97bd1bmr1721567oaj.104.1660145323482; Wed, 10 Aug 2022 08:28:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 10 Aug 2022 17:28:07 +0200 Message-ID: To: Levi Morrison Cc: autaut03@gmail.com, internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000048227605e5e4b493" Subject: Re: [PHP-DEV] [Concept] Extension methods From: deleugyn@gmail.com (Deleu) --00000000000048227605e5e4b493 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 10, 2022 at 5:16 PM Levi Morrison via internals < internals@lists.php.net> wrote: > > What are your thoughts? > > It's a fantastic feature that I've used in Rust, although there are > some differences. First, it doesn't work for regular methods -- they > have to be part of a trait. Secondly, in general a trait can only be > implemented for a given type if it is in the package which defines > that type, or in the package which defines the trait. Third, the trait > must be in scope. These rules help people understand where the methods > are coming from, which is particularly helpful for large code bases or > teams. > > PHP doesn't really have tools for these kinds of restrictions, but I > think it's necessary. You'd need some way to manage where extension > methods are loaded, how they are found, and without pessimizing > performance of method calls in general just because this feature > exists. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > As I was thinking about how this feature would be cool, I was also worried about how big of a mess it could become, given the lack of restrictions you pointed out here. However, knowing how PHP works, I wonder if the following could be made possible: ``` // Vendor File namespace Illuminate\Support; class Collection {} // Extension File namespace App\Whatever; extension LaravelCollection on Collection {} // Usage File namespace App\Business; use App\Whatever\Laravelcollection; $collection = (new Collection())->extensionMethodAvailableHere(); ``` The goal here is to 1- Disallow `use Class; use ExtensionClass` simultaneously (conflicting symbols on compile-time?) 2- Bind the Base-class Symbol through the ExtensionClass symbol 3- Disallow two extensions to compete with each other 4- The user would always know that a symbol has a method either via 1-level extension or from the original class directly - it doesn't come from unknown places I feel like this would be powerful enough to solve a lot of usability on PHP OOP while not being crazy enough to create a nightmare on codebases and the internals of the PHP Engine. Does this make sense? -- Marco Deleu --00000000000048227605e5e4b493--