Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128125
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 18 Jul 2025 13:06:08 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <37d0aa7a-aa94-4e70-914a-3a41a6c4b060@app.fastmail.com>
In-Reply-To: <0e8eb146-3b1d-4fc2-ad83-77062f2063c9@bastelstu.be>
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <09780759-9ddc-45e2-9376-befb8e378775@app.fastmail.com>
 <0e8eb146-3b1d-4fc2-ad83-77062f2063c9@bastelstu.be>
Subject: Re: [PHP-DEV] Re: [RFC] Readonly property hooks
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jul 18, 2025, at 11:29 AM, Tim D=C3=BCsterhus wrote:

>> // New code in 8.5:
>> =20
>> $p =3D new PositivePoint(3, 4);
>> $p2 =3D clone($p, ['x' =3D> -10]);
>
> This is not legal code in PHP 8.5. Clone-with respects visibility and=20
> since your asymmetric visibility RFC included the change, you are=20
> probably aware that `readonly` implies `protected(set)`.
>
> 5.
>
>> but are now necessary to ensure that invariants are enforced.
>
> And therefore with PHP 8.5 hooks are not necessary to enforce=20
> invariants, except in the rare case where a `public(set) readonly`=20
> property is used.

This is a valid point, thanks.  I have updated the example to use `publi=
c(set)`, and note that it means many withX() methods can be eliminated, =
as their restrictions can be placed on the property instead.

Note to self: public(clone) ...=20

> 6.
>
>> So no guarantees are softened by this RFC.
>
> Yes, they are. Unless `__get()` is implemented on a class (which is=20
> explicitly visible as part of the public API), readonly guarantees the=20
> immutability of identity.

Which would also be guaranteed with the "refers to the backing value" pr=
oposal, which you also rejected.

Does readonly refer to the physical value (backing value, object identit=
y) or the "value returned"?  That wasn't a distinction that mattered in =
8.1 when readonly was introduced, though now it does.  If yes, then all =
that needs to be protected is the backing value, so get hooks that respe=
ct that should be fine.

Does readonly refer to the value returned?  If so, that's already been b=
roken since the beginning because the property can be a mutable object, =
so trusting the data returned to be "the same" is already not safe.

At a conceptual level, we need to decide what readonly means.  There is =
clearly no consensus on that right now, and that's going to cause proble=
ms any time we touch readonly, not just this RFC. =20

>> While that is an interesting idea that has been floated a few times, =
it has enough complexities and edge cases of its own to address that we =
feel it is out of scope.
>
> While it certainly is your right as the RFC authors to consider certai=
n=20
> things out of scope for an RFC, I strongly oppose the notion of shippi=
ng=20
> something that is strictly inferior and comes with obvious semantic=20
> issues due to perceived complexity of another solution and then=20
> following up with the proper solution that has already been identified=
.=20
> As I've outlined in my previous emails, I found defining semantics for=20
> an 'init' hook straight-forward when looking at how PHP works as of to=
day.

I suppose this is a valid argument, given that readonly was implemented =
because Nikita felt the proper solution of full aviz would be too comple=
x so went with the simpler solution, which, turns out, is strictly infer=
ior and comes with obvious semantic issues.

> After reading through the discussion, it seems the only argument again=
st=20
> the 'init' hook is perceived complexity. It is not at all clear to me=20
> why this means that we must now rush something with clear issues into=20
> PHP 8.5.

At this point, I fully expect the 'get' part of the RFC to not pass.  So=
meone else is welcome to then work on an init hook.  The seemingly less =
controversial 'set' hook still has considerable value on its own, and ho=
pefully that passes.

--Larry Garfield