Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114801 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 85225 invoked from network); 9 Jun 2021 16:37:23 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 Jun 2021 16:37:23 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 26A761804F4 for ; Wed, 9 Jun 2021 09:52:26 -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.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 9 Jun 2021 09:52:25 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 68EE25C010A for ; Wed, 9 Jun 2021 12:52:24 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Wed, 09 Jun 2021 12:52:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=jbqnls l3J/D96w7x3qp7zx/vJBnIyYWsQrKsYKDaOG8=; b=kHcMEgkeN2Inv7/Ha7zDrS 4SZF1QnKsiM1bpDJG4tv6el96VHQp5Hwg6AbUKkjb0jn4xyhkXgLLH3Pw7FoUjGw Cs67vqihEvL4Lsi1roBp01Tcpi6/f94B8E+WX6PG1ofmTem68UZbHzm4bL4aupqW cAm8JIueFaPgKRRrVQIWsZaPDqWq3p4nYwAufSy77t+88onefaoCk1vCEM/uHJ7S Sd5PNQZslSq42HKjnA5UZH5HlH+rC2ZKCSl98SI4LwO6rkrV9Ou0h4QRydcyYcko iMaw6sgdWXPejVV2fYWqb2np/aDZ1ICKPQFj6mlpIb1oDIwUdPzV7A0lmfTmVXaQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeduuddguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgr rhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtg homheqnecuggftrfgrthhtvghrnhepleduheffhfegieffgffgvdekjeeghedvffehudev uddtheeiudefieefvdejueegnecuffhomhgrihhnpehphhhprdhnvghtpdgrnhhnohhtrg htihhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D1A9AAC0073; Wed, 9 Jun 2021 12:52:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-519-g27a961944e-fm-20210531.001-g27a96194 Mime-Version: 1.0 Message-ID: <7a40dd68-6e44-4b2a-83e2-956fe00c9e6e@www.fastmail.com> In-Reply-To: References: Date: Wed, 09 Jun 2021 11:51:35 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC] Readonly properties From: larry@garfieldtech.com ("Larry Garfield") On Wed, Jun 9, 2021, at 5:05 AM, Pierre Joye wrote: > Hi Nikita, > > On Fri, Jun 4, 2021 at 10:19 PM Nikita Popov wrote: > > > > Hi internals, > > > > I'd like to open the discussion on readonly properties: > > https://wiki.php.net/rfc/readonly_properties_v2 > > Very good work, thank you :) > > > This proposal is similar to the > > https://wiki.php.net/rfc/write_once_properties RFC that has been declined > > previously. One significant difference is that the new RFC limits the scope > > of initializing assignments. I think a key mistake of the previous RFC was > > the confusing "write-once" framing, which is both technically correct and > > quite irrelevant. > > > > Please see the rationale section ( > > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this > > proposal relates to other RFCs and alternatives. > > About this paragraph in > https://wiki.php.net/rfc/readonly_properties_v2#rationale: > > " The addition of readonly properties neither precludes nor > discourages the addition of asymmetric property visibility." > > To me this sentence is the meaning of a readonly property, not an > immutable property, as in writeable once property, in constructor. > > This RFC is perfect given its goal but the property attribute "readonly". > > How would you define a property only readable from outside the scope > but writeable inside the scope of its class (->status f.e.)? > > This is PHP and we always have our ways. That being said, the keyword > "readonly" is really about what is defined as "asymmetric property > visibility" in many other languages. Rust uses annotation, .net via > either readonly and they use an init setter to make it immutable in > v9 (public DateTime RecordedAt { get; init; }), other like java or > scala relies on setting a property getters only. > > Given this, I wonder if it would not be easier to have actual per > property getter/setter as an addition or replacement to the current > (kind of horrible) get/set($name, $value). This would all cases in > one shot, a more complicated shot but much more powerful. For the > record, I am totally not a fan of the 'manual" get/setMyProperty ;) > > In any case, I would at least put a second thought on the name "readonly". > > ps: sorry if this question has been discussed in previous RFCs, > pointers appreciated as I did not find it :) > > Best, > -- > Pierre Pierre and Mike: "Asymmetric visibility" as we keep referring to it would mean the "implicit accessors only" version of this: https://wiki.php.net/rfc/property_accessors That is, it would let you define public/private/protected for get and set operations on a property separately from each other. There are three key differences between readonly and asymmetric visibility as described there: * Asymmetric visibility would allow a property to be reassigned multiple times from within a class, readonly would allow writing to it only once when it's uninitialized. Whether one of those is too-tight or too-loose is a matter of opinion and context. * Asymmetric visibility is deliberately a syntax that is forward-compatible with explicit accessor methods in the future. readonly would be a separate, independent feature/syntax. * Asymmetric visibility, IMO, is a stand-alone useful feature. readonly would be most useful if combined with a separate clone-with operator (discussed elsewhere). Whether readonly is useful enough on its own without that to justify its passage without a clone-with RFC also under discussion is an open question, and largely what we've been debating. Both approaches would eliminate *most* uses of __get/__set, which I think everyone agrees is a win. (Nikita, I hope I represented that accurately.) --Larry Garfield