Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119255 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 87899 invoked from network); 10 Jan 2023 18:29:16 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Jan 2023 18:29:16 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A2EA31804B0 for ; Tue, 10 Jan 2023 10:29:15 -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=0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,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-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (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 ; Tue, 10 Jan 2023 10:29:12 -0800 (PST) Received: by mail-vk1-f182.google.com with SMTP id q141so3431257vkb.13 for ; Tue, 10 Jan 2023 10:29:12 -0800 (PST) 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:subject:date:message-id:reply-to; bh=IBSnNpig1HDbZ0c7pXYPH4Z5fPCu9GmhTTEAq7Ha44k=; b=hjKXT7BG8db2xoZcI8LLQotzL+XGmjdt6o11pHRrgqjp+65UJcjMAlcrbOwfV8sIYq jgIHoKyl6bOLkrvrsSIbd67Vr8YYf6FzXusB1YOJo796gZRd1dDcVuIjhjr8mI2CdcNa CA04rEYM9TbZTU3lESGY/YfXH8NZy2aXr0pWJdYtwCjsmRnG+qxbnw9Cj48vnR46LkAQ quROzts/RfnZwad0IlDP7lxiDag4QmPFgZSJ1hkjcFbazcTiC1zgUXGg1ZPzCygD05sS FWaRasK7ngZgrbfE1lwgSP8kICGojOteG8w8G7TKdrTWbX/Crx9zCVbBH1yIIQ5g0sSz sxNA== 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:subject:date:message-id :reply-to; bh=IBSnNpig1HDbZ0c7pXYPH4Z5fPCu9GmhTTEAq7Ha44k=; b=SYlres3/4QuuQXlJZYaeCD5EJZEz7+3TsBZciCtx8k1fM0lqF02dMI7idftYDtS+8a JOd12cIhVb9f3IswKct0pQVFfEKZ//hnEhoBaxYYP2HP3hoKZFjS6gNAMXvkCsWGx2yo UB+UJfbycOnIZB3Hd5+zXwulkZaTS5Cky3G/Ctu6mK6II/ea5Thc1mRQs5qSLmx7N+RX FikZYIKoShieYw25Mrdkb9KPjj/Mb2+EeynuwfdhKngeeDwT8On4QgSfcv5drxvEI1YP jzE1Q4cBIRZbYmipE+p0RLt6FuFqzvIpucRdPXVeH9Br16XwpqJ9907xaUKQsQPz8anL SXNQ== X-Gm-Message-State: AFqh2kofojHS5mTejng+XEdnlNx75hZl9Y8uszruZEinKmsFyrgLmYEN RWHynlEglNKU8RVbS1Yg7Ho8TDWWcNsVYi9kN1MzBaKd X-Google-Smtp-Source: AMrXdXs2q4sjjiF/6HM8rQY8UV1HDN9dbE1Q+8F/kkBz03iJOo80l4vHs/fdmP4FtB/EexKOs3t7nVvGhIzSg41OWjw= X-Received: by 2002:a1f:310c:0:b0:3d5:911f:daed with SMTP id x12-20020a1f310c000000b003d5911fdaedmr6137071vkx.39.1673375351386; Tue, 10 Jan 2023 10:29:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 10 Jan 2023 12:29:00 -0600 Message-ID: To: Thomas Nunninger Cc: php internals Content-Type: multipart/alternative; boundary="0000000000006538db05f1ed0f55" Subject: Re: [PHP-DEV] [RFC][Vote] Asymmetric Visibility From: mweierophinney@gmail.com ("Matthew Weier O'Phinney") --0000000000006538db05f1ed0f55 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 10, 2023 at 11:19 AM Thomas Nunninger wrote: > I doubt, there would be any need for readonly if we would have had > asymmetric visibility first. And (using asymmetric visibility) I assume, > developers should be able to ensure that a property is 1. only > initialized once, 2. inside the limited scope of a class, and 3. not > overwritten during the lifetime of the object. I'd be interested in a > use case where you would really like to ensure this on the engine level. > > To go one step further, I would even ask the heretical question if we > should discourage/deprecate readonly once we have asymmetric visibility. > ;-) > I disagree. They serve different use cases. In the case of readonly, it's an easy way to also define _immutable_ classes. Aviz doesn't provide that; in fact, it is a way to explicitly allow use cases where changes can be made, while still providing direct access to a property. Yes, you _could_ add logic to a class to prevent changes after initialization... but marking a property as readonly does that for you, in a way that is less error prone than userland logic. -- Matthew Weier O'Phinney mweierophinney@gmail.com https://mwop.net/ he/him --0000000000006538db05f1ed0f55--