Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118390 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94650 invoked from network); 8 Aug 2022 11:22:30 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Aug 2022 11:22:30 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8068E180339 for ; Mon, 8 Aug 2022 06:23:47 -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,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS398810 136.175.108.0/24 X-Spam-Virus: No X-Envelope-From: Received: from mail-108-mta92.mxroute.com (mail-108-mta92.mxroute.com [136.175.108.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 8 Aug 2022 06:23:46 -0700 (PDT) Received: from filter006.mxroute.com ([140.82.40.27] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta92.mxroute.com (ZoneMTA) with ESMTPSA id 1827da01b7b0000261.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Mon, 08 Aug 2022 13:23:41 +0000 X-Zone-Loop: c441db61b877dbc1e6ebaa665ed78483119b156da5b4 X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=demon-angel.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:To:Subject:Reply-To:MIME-Version:Date:Message-ID:Sender:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jiwWrFwKX4p8+YAL+/Ciwyvc6m5UkyUTvT6HTodSkxU=; b=PckWI4k6kIpUB+27pJqwUSwo+X HjFstAtsd39Ubl2eUhBn2C7eyzUE/IlpztaTH6PxE6d37CnytFVkxzefCP+qeKOpiXH0R8qiUSRfk hoKuR1muGpcuJtDa8RiT9n4FexwR7t6icVpioESQlS6V4u99WaENvmJZCGfNrbTVb5RmQOY460COI 0kYjJmykvLONM6ZBy1SSnlf4BVct1ZZCq2ZplRGRNzNEWIvNdqMxJUpVi5qyQfmLLkNUxFhcj3770 7gzl+xj/9I7RD2XylTNt+7wl3o/JvxQk7X8tTRhWlYMDeAb+I7hSHxrVPU0HeQIszHZWMMB7mCj1j BKgss1RQ==; Message-ID: <360c1ff4-999e-4473-1a74-8b54ead3358e@demon-angel.eu> Date: Mon, 8 Aug 2022 15:23:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Reply-To: mark@demon-angel.eu To: internals@lists.php.net References: <640e0f95-de30-4c53-48e8-818fdf408112@heigl.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: mark@demon-angel.eu Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility From: mark@demon-angel.eu (Mark Baker) On 08/08/2022 10:14, Marco Pivetta wrote: > As for `readonly`, the reason we sometimes **cannot** use `readonly` is > because current `clone` semantics can't work around `readonly` rules > (discussed in the `readonly` RFC):https://3v4l.org/og8bn > If we solved that, I think `private(set)` would become even more > situational, if not completely unnecessary. I'm with Marco on this; the majority of use cases for asymetric properties could be resolved if internally cloned objects could update their readonly properties. And I also find the syntax looks odd, and not like any other aspects of PHP, not to mention the potential length of property definitions -- Mark Baker _________ |. \ \-3 |_J_/ PHP | || | __ | || |m| |m| I LOVE PHP