Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128178 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 7C3441A00BC for ; Tue, 22 Jul 2025 11:40:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1753184352; bh=WvmG3WL/ZcOh6xMSdLr6Hcg+G1KrGnOj3CqFCZNfa60=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ABeSwsML5UepeIgpH7iEk6odYKhle2JEnxCJgNVnfCLBTLvT8mOxHYiEK3jtZ/FcA EeqAvGflzrJK/OqJbmZ+lHy4EifT/yeF20qrG6xM+Hr5HYtLQt5wHzMXaTI73D8naX fQ4CJkNFmpkmWAEpx8p0rAiRvppIuagKi6DyDKY2mi7WRD9Um5+MFFfUk4gpf+MusL 7iu+tCuH9feRde0ywTmlh8FpU3v6xwajLAjrbs17try2xTcz477lSuq9BTLlMpOLa8 tKjpt5OkMyDm6ua6u8mjOz1f/NYKZ7emhR+l9nJgWPLop6HU73v6naQAvEboPYj/W3 QMuttkgTQjXEw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DC6EF180079 for ; Tue, 22 Jul 2025 11:39:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) 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,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 22 Jul 2025 11:39:10 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id AD65BEC0327; Tue, 22 Jul 2025 07:40:55 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-05.internal (MEProxy); Tue, 22 Jul 2025 07:40:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1753184455; x= 1753270855; bh=WvmG3WL/ZcOh6xMSdLr6Hcg+G1KrGnOj3CqFCZNfa60=; b=T hah74aul/kVdcVYDuoBdGk92s91Io2AEW8IPNQEj46a1WiHIbayanXLYUpOLVJpM UQ60rEDlkTDp7sd1x5vMo3ZygfziE8dvq2K9BepKXaVbQ58emVjXp78GAkD33yHt +6mi1SRvia3jawanCiUUVm0zR8DSAqGKmJ/7zvCFFdhZelBFVfI7xBTUHftgtDYb OMbicaFBxcd4XBPqUr83Jcy3qB5FsBmum6CCUmF4YW/zB9u1FfDZg+cI/ns3lcm1 5r5USFNd/R8tDvHTO3Tycmk0mMulsoBp+NM85JHLaF1A4BzOP2EhAdfnL3dKYINn kEsm2XglOyESYiyUyK5PQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1753184455; x=1753270855; bh=WvmG3WL/ZcOh6xMSdLr6Hcg+G1KrGnOj3Cq FCZNfa60=; b=CdbaxHlHZK3+C7QZ45006UIkFCgs6QVKs21zGx4xo77Sn449epv Spwlv89hjdCkqlcyJhnXWmakGAL8lEL/UOrs52bD2B2/q042CFVlp2YMw8ZP3Gw0 n/6fVGWrKM4zQVJ9tEKizyBmTq0i1PEsE6izJakkksR3sDDwGYMZsC6aFBU1Dkd0 4OcKIndy5a+qZ89wxH2M33vbotTU7qPPTAru6MSUWGlWInBXwQSPqBkghLw5nueF YYlJkkNIBfQQl8u7N9OwHcpHKE3hI1fWmZaV3CzQO3HW7e9VWGJj6n7R4UUnZtYX O2kBS2+69NTRFm5Dasq0iX58gn9S7en3ZqQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdejgeekudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefoggffhffvvefkjghfufgtsegrtderreertdejnecuhfhrohhmpedftfhosgcunfgr nhguvghrshdfuceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrfgrthhtvg hrnhepffffgfffudeileehvdegfedtueefgeehfefghedvleekueeffeffledtieejhedt necuffhomhgrihhnpegvgihtvghrnhgrlhhsrdhiohenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghs pdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegtlh gruhguvgdrphgrtghhvgesghhmrghilhdrtghomhdprhgtphhtthhopegvrhhitghtnhho rhhrihhssehgmhgrihhlrdgtohhmpdhrtghpthhtohepihhnthgvrhhnrghlsheslhhish htshdrphhhphdrnhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 35DA2182007A; Tue, 22 Jul 2025 07:40:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: T0d65545c0179fcf6 Date: Tue, 22 Jul 2025 13:40:28 +0200 To: "Claude Pache" Cc: erictnorris@gmail.com, "php internals" Message-ID: In-Reply-To: References: <378cd8b0-c4a8-4e53-b0bd-e9e4f30a454d@app.fastmail.com> <77128196-8D53-40D6-9BB7-77160AD71ED9@gmail.com> <247034b6-04cf-4f3e-a145-a30171af8c12@app.fastmail.com> <5a51401a-450b-46f0-8467-88d31efecb9c@app.fastmail.com> <4567d926-aaed-44a8-9cd6-68e8e12742f4@app.fastmail.com> <77df950f-894a-41c1-863b-89871522d14c@app.fastmail.com> Subject: Re: [PHP-DEV] [RFC] Readonly property hooks Content-Type: multipart/alternative; boundary=8d73eb756b6143eaaf56a2564d025676 From: rob@bottled.codes ("Rob Landers") --8d73eb756b6143eaaf56a2564d025676 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2025, at 12:17, Claude Pache wrote: >=20 >=20 >> Le 22 juil. 2025 =C3=A0 11:25, Rob Landers a =C3=A9= crit : >>=20 >>=20 >>>=20 >>>> Should I be able to mark this class as readonly? I would think so. >>>=20 >>> I don=E2=80=99t think so. >>>=20 >>> If you want to *document* the intended invariant, you can put a @rea= donly tag in a phpdoc comment. >>>=20 >>> Adding a `readonly` keyword should *enforce* the invariant; the adde= d value is that it would choke on bugs like the one you wrote just above= , making it debugging much easier. >>=20 >> I=E2=80=99m not sure if you meant to, but I feel like you just argued= for allowing readonly on hooks so that these kinds of bugs aren=E2=80=99= t accidentally written=E2=80=A6 >=20 > You are misinterpreting my statement, and I=E2=80=99m not sure how I c= ould be clearer (additional words will be subject to additional misinter= pretation). I didn=E2=80=99t say: =E2=80=9Cwe should allow `readonly` so= mewhere=E2=80=9D, but: =E2=80=9Cif we add `readonly` somewhere, it shoul= d enforce what it means, not just document an intent=E2=80=9D. If words could only be interpreted one way, we wouldn't need lawyers and= clergy. I think it is worth clarifying if you are willing. But I do thi= nk we agree that it should be enforced -- it just comes down to the what= and how it is enforced. >=20 >>=20 >>>=20 >>>=20 >>>> The readonly keyword simplified that greatly, however, readonly has= been neutered compared to regular classes in the last couple of version= s. There are so many edge cases and non-implemented features with them -= - mostly due to this exact argument you are making -- that they're nearl= y worthless to actually define immutable value objects in today's PHP. >>>>=20 >>>=20 >>> There are several issues with the readonly feature, mostly because o= f the =E2=80=9Cworse-is-better=E2=80=9D philosophy. But we can slowly co= rrect the main issues instead of making them worse. >>>=20 >>> =E2=80=94Claude >>=20 >> I think this is the main crux of the issue, right? There is one camp = that says readonly means immutable and another that says readonly is rea= d-only. These two viewpoints are not compatible despite having a lot of = overlap. >=20 > The original RFC explicitly and unambiguously gives the intended inter= pretation, despite your attempts to find another interpretation in it. I= agree that the word =E2=80=9Creadonly=E2=80=9D is badly chosen and conf= using. But I don=E2=80=99t agree that we should reinterpret any feature = based on incorrect understanding of its intent (unless, of course, there= is consensus to reinterpret it). >=20 > =E2=80=94Claude If it were unambiguous, we wouldn't be having this conversation. I'd als= o invite you to read the original discussion: https://externals.io/messa= ge/114729. Note that it is pretty clear that readonly and aviz/hooks ove= rlap, even back then. We do need to discover this overlap, and how it ov= erlaps. Maybe that isn't this RFC, but where they overlap, they should b= e able to be used together. Or not? I dunno. =E2=80=94 Rob --8d73eb756b6143eaaf56a2564d025676 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 22, 2025, at 12:17, Claude Pache wrote:


Le = 22 juil. 2025 =C3=A0 11:25, Rob Landers <rob@bottled.codes> a =C3=A9= crit :



Shou= ld I be able to mark this class as readonly? I would think so.

I don=E2=80=99t think so.
=

If you want to *document* the intended invariant, yo= u can put a @readonly tag in a phpdoc comment.

= Adding a `readonly` keyword should *enforce* the invariant; the added va= lue is that it would choke on bugs like the one you wrote just above, ma= king it debugging much easier.

I=E2=80=99m not sure if you meant to, but I feel like you just argued= for allowing readonly on hooks so that these kinds of bugs aren=E2=80=99= t accidentally written=E2=80=A6

<= div>You are misinterpreting my statement, and I=E2=80=99m not sure how I= could be clearer (additional words will be subject to additional misint= erpretation). I didn=E2=80=99t say: =E2=80=9Cwe should allow `readonly` = somewhere=E2=80=9D, but: =E2=80=9Cif we add `readonly` somewhere, it sho= uld enforce what it means, not just document an intent=E2=80=9D.

If words could only be interpreted = one way, we wouldn't need lawyers and clergy. I think it is worth clarif= ying if you are willing. But I do think we agree that it should be enfor= ced -- it just comes down to the what and how it is enforced.
=


=


=
The readonly keyword simplified that greatly, however, readonly has= been neutered compared to regular classes in the last couple of version= s. There are so many edge cases and non-implemented features with them -= - mostly due to this exact argument you are making -- that they're nearl= y worthless to actually define immutable value objects in today's PHP.


There are seve= ral issues with the readonly feature, mostly because of the =E2=80=9Cwor= se-is-better=E2=80=9D philosophy. But we can slowly correct the main iss= ues instead of making them worse.

=E2=80=94Clau= de

I think this is the main = crux of the issue, right? There is one camp that says readonly means imm= utable and another that says readonly is read-only. These two viewpoints= are not compatible despite having a lot of overlap.

The original RFC explicitly and unambiguously g= ives the intended interpretation, despite your attempts to find another = interpretation in it. I agree that the word =E2=80=9Creadonly=E2=80=9D i= s badly chosen and confusing. But I don=E2=80=99t agree that we should r= einterpret any feature based on incorrect understanding of its intent (u= nless, of course, there is consensus to reinterpret it).

=E2=80=94Claude

If= it were unambiguous, we wouldn't be having this conversation. I'd also = invite you to read the original discussion: https://externals.io/message/114729. Note t= hat it is pretty clear that readonly and aviz/hooks overlap, even back t= hen. We do need to discover this overlap, and how it overlaps. Maybe tha= t isn't this RFC, but where they overlap, they should be able to be used= together. Or not? I dunno.

=E2=80=94 Rob
--8d73eb756b6143eaaf56a2564d025676--