Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118994 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 71905 invoked from network); 13 Nov 2022 20:09:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Nov 2022 20:09:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7C780180083 for ; Sun, 13 Nov 2022 12:09:14 -0800 (PST) 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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29838 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (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 ; Sun, 13 Nov 2022 12:09:13 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 758CE320085B for ; Sun, 13 Nov 2022 15:09:12 -0500 (EST) Received: from imap50 ([10.202.2.100]) by compute1.internal (MEProxy); Sun, 13 Nov 2022 15:09:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; t=1668370152; x=1668456552; bh=VUV4qoFnMM wyym6zjs3BMJRWomxV0cW44QsbZc/mL60=; b=fjyJkK7cGhcudEk+74rtRI8z1o 0sq0ufkpImbg1bws62jGS30RMT2tz9ccVgc3irS0zav1ZccV0pEBBoM9MiIUNv5Z aIX0apCMr4lLY6w7Q/m3Onhp45mSSsLK6/bkBFGExag9wAPaEqnaDP4PRRQwRXPd 1yv1wtpntSrIz6I8gENyxs5Q5sT75K0HSrk0ZXi7W6EBUCB1ZpursJPx5o9lM+4P rwGX7BccbwI7lsDetasukPHO0vLPIriVXf4DX7wvxbNOqugGxCubmXKJ/lk5oXrN coeVjOhfyAFUuE0Q2kiwf4+igvJjq6Cw47sy3q2AlFdaa0RGMRoLwVgDnEuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1668370152; x= 1668456552; bh=VUV4qoFnMMwyym6zjs3BMJRWomxV0cW44QsbZc/mL60=; b=j W6rvAMNOXoXBVXqF9znP7t0bKJvnHN2sMqNQYP/i1DUiLeXPQHJjs6ag3rsDG6fC 50QJAlGJ5TiXTVNW2zqqwUZ4u0iNXBzIhhgVb8eucStetRbAIBAgQ4Y4nFsMz0Jr b/4IaogA93m1Ah3AvdIMjfw+W8hGZq81v3uYVIH27klqjYEeiUiHtxMSPTjEH3Bi KGsYceIxHnHCZLOhy1jivgnDDUuLdi4fU3r4eh4NjAtKWoHbipOTMORM63tm+FZx ews9QySflJ+xBTF74NX+COGoD8z5U4q/Y1E69NW7a3r7SUGqmJDVThIRJWkFSmLr JKU6RLnihnBfLab8/YkBw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrgedtgddufeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghrrhih ucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhmqe enucggtffrrghtthgvrhhnpeefteejkeelgeevtedvkeduiedttdeljeeguedthfefkeet ffegieeuteejieeigfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id D40D81700093; Sun, 13 Nov 2022 15:09:11 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-ID: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com> Date: Sun, 13 Nov 2022 14:08:01 -0600 To: "php internals" Content-Type: text/plain Subject: [RFC] Asymmetric Visibility, with readonly From: larry@garfieldtech.com ("Larry Garfield") Hi folks. Ilija is nearly done with the implementation for asymmetric visibility and flushing out edge cases, but we've run into one design question we'd like feedback on. There's two design decisions we've made at this point, both of which we think are logical and reasonable: 1. If specified, the set visibility must be tighter than the get visibility. So `protected protected(set)` and `protected public(set)` are not permitted, for instance. 2. `readonly` is a "write once" flag that may be combined with asymmetric visibility. If no set visibility is specified, `readoly` implies `private(set)`, but a different set visibility may also be provided. These are both reasonable rules. However, it creates a conflict. Specifically, in the following cases: public public(set) readonly string $foo protected protected(set) readonly string $foo These would be the only way to have a non-private-set readonly property. While the first is in practice quite unlikely, the second has valid use cases. (In particular, a base class that provides properties expected to be set by a child constructor, and then used by a method in the parent class.) However, it would not be allowed under the rules above. Working around it would require specifying `public protected(set) readonly...`, which means exposing a property that likely should not be exposed. That creates an odd situation where readonly and asymmetric visibility may only be combined "sometimes." That is not deesireable. The only way to combine them in their current form is to allow `protected protected(set)` only if readonly is in use, which is excessively complicated both to implement and to explain/document/use. We see two possible ways to resolve this conflict: 1. Relax the set-is-tighter restriction. That would allow `protected protected(set)` etc. on any property. It wouldn't be particularly useful unless readonly is being used, but it would be syntactically legal and behave as you'd expect. We could still disallow "set is more permissive" combinations (eg, `private public(set)`), as those have no apparent use case. 2. Disallow readonly and asymmetric visibility being combined, because readonly already has a hard-coded implied asymmetric visibility. This option removes some potential use cases (they would most likely drop the readonly), but has the upside that it's easier to re-allow at some point in the future. 3. Some other brilliant idea we've not thought of. Both are viable approaches with pros and cons. We're split on which way to go with this, so we throw it out to the group for feedback. Which approach would you favor, or do you have some other brilliant idea to square this circle? -- Larry Garfield larry@garfieldtech.com