Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127550 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 11EA81A00BC for ; Tue, 3 Jun 2025 04:34:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1748925172; bh=byucimq78oKaNe8sTitJoAkBq5lxefVNqKmYy1m/kLY=; h=From:Subject:Date:References:To:In-Reply-To:From; b=E/tYNP1NDG+aLqHLHr+dM5e8AJ5UCNubdKPDx4PVbOxaoJleAjKW743sXoYMfKDYp fYy3+NeM4BF4KqlLanw2Cwbwd1pyeXAWltJZ6Ols5IxEeiSKCyQLzFQl4nN92Jr4Bl l9gQogNZSciC8KOUZkVCu/NInT2fTbR/xqufuMN6Xaetdh990znq/zyhzzOq4tEcwb XdVyUvXfKuMIDjpvb9YgCiB/CoBYy0Gt4PjE05YaGsM92IKLYdawnnD/OQwQbWSdbb UjMf0+qgBpcWbltIkPot9f8ks7xDam5IfGqeaSTruaU+bldZaqJt16e1uo6K3Tnl0N o2gAevc8DxzEg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 01227180041 for ; Tue, 3 Jun 2025 04:32:50 +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=3.9 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,HTML_MESSAGE, RCVD_IN_SBL_CSS,SPF_HELO_NONE,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 avril.gn2.hosting (avril.gn2.hosting [84.19.162.247]) (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, 3 Jun 2025 04:32:50 +0000 (UTC) Received: from avril.gn2.hosting (localhost [127.0.0.1]) by avril.gn2.hosting (Postfix) with ESMTP id 096061C40840 for ; Tue, 3 Jun 2025 06:34:53 +0200 (CEST) Received: from smtpclient.apple (unknown [113.210.105.67]) by avril.gn2.hosting (Postfix) with ESMTPSA id 474561C40180 for ; Tue, 3 Jun 2025 06:34:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nicksdot.dev; s=default; t=1748925288; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JV2TUmDsTdQ1mSB0uejWirdSDMEhgRrwr3zh1GTC4Y0=; b=nmdWAKLxLBdFMoKLDothPktuxVEa4hK2FZ9uTDmQezxOqNLImErRAUGNlnVyBRDBgQtOE6 od228/3XUM7LF0MBYcbZu31fmlovhvLEYwh6rY6B2QCrhgLEvVzyV+jj9SwUjUri62ToOH sa/8jx/qvfSzlatiWz3nXWdNjcEpQei++dFTUSPeuqeEagHCJ//aft1kdOi2bK3x3n4/Z/ VykkP8AcJRlZFsfDjJ9etNDzd2L6tdrmL0kfeNpto5Fs+Qe0XBQ/CMtPkcVS1r/OLDfu7Z CQ3QWlkFbykfOQ37pbmJgPkzcM5jttTMIkaptqDg1IYKexJcC69zOao2sS/rWA== Authentication-Results: avril.gn2.hosting; auth=pass smtp.auth=php@nicksdot.dev smtp.mailfrom=php@nicksdot.dev Content-Type: multipart/alternative; boundary="Apple-Mail=_0D4FC26C-0AE0-4E31-A4F7-9E35776C03C0" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\)) Subject: Re: [PHP-DEV] Allow hooks in `readonly` promoted properties Date: Tue, 3 Jun 2025 12:34:32 +0800 References: To: internals@lists.php.net In-Reply-To: Message-ID: <28F14D0F-8483-418D-85D1-660564A4EAE2@nicksdot.dev> X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; BAYES_HAM(-3.00)[100.00%]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ZERO(0.00)[0]; NEURAL_HAM(-0.00)[-0.983]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:9534, ipnet:113.210.105.0/24, country:MY]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[nicksdot.dev:s=default]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; SURBL_MULTI_FAIL(0.00)[garfieldtech.com:server fail,smtpclient.apple:server fail,wiki.php.net:server fail] From: php@nicksdot.dev (Nick) --Apple-Mail=_0D4FC26C-0AE0-4E31-A4F7-9E35776C03C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Larry, Thanks for your answer. > On 2. Jun 2025, at 21:39, Larry Garfield = wrote: > This was discussed heavily in the design and discussion phase for = hooks. The main problem is that the expectations for readonly and the = expectations for hooks don't always align. For example, if a virtual = property has a get-hook, can it be readonly? We cannot guarantee that = the property will always return the same value, but that is rather the = expectation of readonly. For me, `readonly` is relevant for set operations. It gives me certainty = that a value can only ever be set once. I don=E2=80=99t see how it must = be related to retrieving a value. > Given how large and complex the RFC was already, we collectively = decided to punt on that question until later. Ilija and I did tepidly = propose loosening the restriction slightly: >=20 > https://wiki.php.net/rfc/readonly_hooks >=20 > Though we've not gotten back to it as we've both been busy and there = hasn't been a ton of calls for it, and it likely still needs to be = tweaked some. Yeah, so here I am, with a call after the feature was in the wild for a = while. Hoping that others might chime in with their own experiences and = opinions. I wasn=E2=80=99t aware of this follow up RFC exists. Excited to see it! Limiting it to backed properties feels sensible. I guess it still would = solve the majority of use-cases already. Especially around dumb value = objects. I would like to add, personally, I don=E2=80=99t believe the above is = dumb: ```php class Dumb { public readonly int $value { get =3D> $this->value * random_int(1, = 100); } } ``` I think it is a legitimate use-case. Why wouldn=E2=80=99t a `readonly` property allow us to format, cast or = however mutate a =E2=80=9Conly once written value=E2=80=9D on = consumption? It will not change the underlying value. If it makes things easier for us, allow it. It=E2=80=99s not like this = is some hidden implicit behaviour. We consciously must add the extra = code, hence expect the output to be changed accordingly. So, I would love to see this RFC to be implemented. Maybe you want to move it to discussion? Then my separate thread here = would be obsolete. > Another possibility might be to have the readonly marker on a class = just skip applying to virtual properties. So you cannot specify it = explicitly, but a class-level readonly no longer causes a conflict. I = don't know how viable that is off hand. I don=E2=80=99t have a strong opinion on virtual properties. At first = glance this feels too implicit to me.=20 Given their complexity, rather not allow it for virtual properties (for = now). We can use getter methods for that. The follow up RFC is good as is and a low-hanging fruit with high = positive impact, if you ask me. -- Cheers & thanks, Nick= --Apple-Mail=_0D4FC26C-0AE0-4E31-A4F7-9E35776C03C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hey = Larry,

Thanks for your = answer.

On 2. Jun = 2025, at 21:39, Larry Garfield <larry@garfieldtech.com> = wrote:
This was discussed heavily = in the design and discussion phase for hooks.  The main problem is = that the expectations for readonly and the expectations for hooks don't = always align.  For example, if a virtual property has a get-hook, = can it be readonly?  We cannot guarantee that the property will = always return the same value, but that is rather the expectation of = readonly.

For me, `readonly` is = relevant for set operations. It gives me certainty that a value can only = ever be set once. I don=E2=80=99t see how it must be related to = retrieving a value.

Given = how large and complex the RFC was already, we collectively decided to = punt on that question until later.  Ilija and I did tepidly propose = loosening the restriction slightly:

https://wiki.php.net/rfc/= readonly_hooks

Though we've not gotten back to it as we've = both been busy and there hasn't been a ton of calls for it, and it = likely still needs to be tweaked = some.

Yeah, so here I am, with a = call after the feature was in the wild for a while. Hoping that others = might chime in with their own experiences and = opinions.

I wasn=E2=80=99t aware of this follow = up RFC exists. Excited to see it!

Limiting it = to backed properties feels sensible. I guess it still would solve the = majority of use-cases already. Especially around dumb value = objects.

I would like to add, personally, I = don=E2=80=99t believe the above is = dumb:

```php
class Dumb = {
public readonly int $value { get =3D> = $this->value * random_int(1, 100); = }
}
```

I think it is a = legitimate use-case.
Why wouldn=E2=80=99t a `readonly` = property allow us to format, cast or however mutate a =E2=80=9Conly once = written value=E2=80=9D on consumption? It will not change the underlying = value.
If it makes things easier for us, allow it. It=E2=80=99s = not like this is some hidden implicit behaviour. We consciously must add = the extra code, hence expect the output to be changed = accordingly.

So, I would love to see this RFC = to be implemented.
Maybe you want to move it to discussion? = Then my separate thread here would be = obsolete.

Another possibility = might be to have the readonly marker on a class just skip applying to = virtual properties.  So you cannot specify it explicitly, but a = class-level readonly no longer causes a conflict.  I don't know how = viable that is off hand.

I don=E2=80= =99t have a strong opinion on virtual properties. At first glance this = feels too implicit to me. 
Given their complexity, rather = not allow it for virtual properties (for now). We can use getter methods = for that.
The follow up RFC is good as is and a low-hanging = fruit with high positive impact, if you ask = me.

--

Cheers= & thanks,
Nick
= --Apple-Mail=_0D4FC26C-0AE0-4E31-A4F7-9E35776C03C0--