Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118411 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 51335 invoked from network); 11 Aug 2022 11:49:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Aug 2022 11:49:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DBD8D18053F for ; Thu, 11 Aug 2022 06:51:03 -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_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-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) (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, 11 Aug 2022 06:51:00 -0700 (PDT) Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-31f661b3f89so172868967b3.11 for ; Thu, 11 Aug 2022 06:51:00 -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=0vYVajLfHa65feT+e8bdKsDzUGY/0oDEnOHpvfvpJL0=; b=ZP03ikcuk1Yn1Dm+AYWVhuA7maqh48eeTGuDu0Yph/EHezwf5eC2wcTvdWtgyv4wKL MFzVhsi4I8xyj7h+cGQ/IKf6+j19EU3AQfMEYKVfHYp0lww4f2upP6k4qDq4wqthMkt8 mv3CbnTdr94ynq1MftqZNUpaI2geN8vU1MS+JqcByQmU5SOyS0R10X8XJKgSCEqOvFLl GP8QELJ0RqVr0ZBD5B/YPvMVXlKve8R8fTngGg+169v1nEErUbON2KrgA804moORrSWf RZWjRPTSpEmgZsQ2/0UqgSe1SLfwhEFMFMxloKRMx9EfzMm/nYuDasCbDJoWCyhLsGQq JkkQ== 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=0vYVajLfHa65feT+e8bdKsDzUGY/0oDEnOHpvfvpJL0=; b=aQ+tmGycnhg6WFf75ZK8i1bzPDDIrUz/XjX9b/Mc4bYkgJNbaPT3mxmtVG/yQoTkMh IMWkW3G2r80W7/a6h66HQywC2jFccczji6L/s80AIUml8p2lLhAaICZ3V45Q0922IBq9 FV41NvS1voe6rPGbspw4HT0wsd2ibtKX9GyL80FqI58uMJtsJa8BUP1Zibby07rhuF3y 1s7ktsMo8vHizXToPHlY2reOPbVhzgVnypqzyFpkO2PoP4tHA6fUEk2xgQhRiMuEwQ32 4xD8st6j+r4WIY/+pHl3pkqh62lXRk6/Edd3pnawR0h5wC17wZQEi6YBiBQrOChMtUPy E7vA== X-Gm-Message-State: ACgBeo33pqU6NId4SMChWHSGzdgW5Hg/AMIuNe40CyVs7iOfXBlEpe/g loasQjRnGCZEUzqAggJ7RNJTLXD/oydcZtMGmDo= X-Google-Smtp-Source: AA6agR7vkfTVtW6uMvwETX/Ex24P8tALCibFjD5xytPL15F/24StSULNemJQSHA1gHxT/dCiej12edtaMmz6CRmpDVQ= X-Received: by 2002:a0d:dc83:0:b0:328:37a2:cb22 with SMTP id f125-20020a0ddc83000000b0032837a2cb22mr33513009ywe.473.1660225859798; Thu, 11 Aug 2022 06:50:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 11 Aug 2022 15:48:06 +0200 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="0000000000009ecc1005e5f774a1" Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --0000000000009ecc1005e5f774a1 Content-Type: text/plain; charset="UTF-8" > Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: > Asymmetric Visibility. > > https://wiki.php.net/rfc/asymmetric-visibility > > Details are in the RFC, but it's largely a copy of Swift's support for the > same. > Thank you Larry and Ilija for this RFC. After reading it, I'm wondering about inheritance rules. What would be the rules when redeclaring an existing asymmetric property in a child class? The RFC should mention them I believe. But I'm also wondering about the use case where asymmetry would be useful in practice now that we have readonly? I voted against readonly at the time because it didn't address cloning, and also because it deprives end-users vs code authors IMHO (alike "final"). I would have very much prefered asymmetric visibility back then. But now that we are here, what are the use cases? If it's cloning only, then I would very much prefer finding a way to fix it rather than providing two subtly different ways to achieve the same thing. Eg can't we allow __clone methods to bypass the readonly restrictions? The engine already handles "guards" when using magic property accessors. Can't we use something similar for clone? And if yes, what would remain of the motivations for the asymmetric RFC? Cheers, Nicolas --0000000000009ecc1005e5f774a1--