Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128145
Precedence: bulk
MIME-Version: 1.0
References: <378cd8b0-c4a8-4e53-b0bd-e9e4f30a454d@app.fastmail.com>
 <77128196-8D53-40D6-9BB7-77160AD71ED9@gmail.com> <247034b6-04cf-4f3e-a145-a30171af8c12@app.fastmail.com>
 <CDB0DA86-50BF-4002-962C-7758E39FF37F@gmail.com> <c4887bd8-e9ff-42f1-aedf-d85a8e12b0e0@app.fastmail.com>
In-Reply-To: <c4887bd8-e9ff-42f1-aedf-d85a8e12b0e0@app.fastmail.com>
Reply-To: erictnorris@gmail.com
Date: Sun, 20 Jul 2025 13:18:16 -0400
Message-ID: <CA+NMNO3DHNNVqBmJh+MW25+fHy1EVuMAV=5OsCbXb6U4sJ-K1Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
To: Rob Landers <rob@bottled.codes>
Cc: Claude Pache <claude.pache@gmail.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: eric.t.norris@gmail.com (Eric Norris)

Hi Rob,

I'm going to respond to a few points from earlier emails here instead
of each one.

On Sat, Jul 19, 2025 at 6:13=E2=80=AFAM Rob Landers <rob@bottled.codes> wro=
te:
>
>
>
> On Sat, Jul 19, 2025, at 12:09, Claude Pache wrote:
>
>
>
> Le 19 juil. 2025 =C3=A0 09:46, Rob Landers <rob@bottled.codes> a =C3=A9cr=
it :
>
>
>
> On Sat, Jul 19, 2025, at 03:04, Claude Pache wrote:
>
>
>
>
> Le 19 juil. 2025 =C3=A0 00:41, Rob Landers <rob@bottled.codes> a =C3=A9cr=
it :
>
>
> The original author (Nikita) suggested that there's nothing in the origin=
al design that precludes accessors -- and highlights languages where there =
are both and they are doing just fine more than 5 years later.
>
>
> Hi Rob,
>
> It is indeed entirely reasonable to have both readonly properties and hoo=
ked properties (aka accessors), and today PHP has indeed both of them (and =
even asymmetric visibility on top of that, as a separate feature contrarily=
 to C#). But it doesn=E2=80=99t mean that it is reasonable for the *same* p=
roperty to be *both* readonly and hooked, which is the point that is curren=
tly disputed. =E2=80=94 What do the other languages allow? Is it possible t=
o define a readonly property with a user-defined getter? (Disclaimer: Even =
if one of them allows such a thing, I=E2=80=99ll still think that it is a b=
ad idea.)

I do not believe I was cherry picking; I share Claude's interpretation
here that the RFC says that readonly doesn't prevent the language from
adopting accessors (hooks) later, which is what the language did, and
notably it did without applying them to readonly properties.

Could you perhaps walk me through your thinking when the RFC claims
that `assert($prop =3D=3D=3D $prop2)` "always holds"?

>
> =E2=80=94Claude
>
>
> Hey Claude,
>
> From what I've seen in other languages, this combination is fairly common=
 and not inherently poblematic.
>
> - C# allows get hooks with user-defined logic, even in readonly structs.
> - Kotlin uses val with a get() body, which is readonly from the consumer'=
s perspective, even though the value is computed.
> - TypeScript allows a get-only accessor which acts readonly.
> - Swift also allows get-only computed accessors/hooks.

(disclaimer, I am not a C# expert)

It seems that C# has both fields and properties, and a readonly field
seems to align with what a few of us are claiming is how PHP readonly
properties should work. C# properties are more open-ended, and don't
actually support the readonly keyword - you can make them "read only"
in the sense of only having a get accessor (and you can mark that
accessor itself as readonly), but this is different from readonly
fields, which enforce a contract about the mutability of the field.

I think that C# fields, both readonly and not, match PHP's properties
without hooks. C# properties - which I believe cannot be *marked*
readonly, but they can be *made* read only, i.e. only exposing a get
accessor - match PHP's properties with hooks.

>
>
> Hi Rob,
>
> The main problem is that we don=E2=80=99t agree on the meaning of =E2=80=
=9Creadonly property=E2=80=9D.

I agree with Claude here. Rob, I'm curious how you interpret the
contract of readonly. Do you think that it is a contract about
writability to consumers of the class? In an earlier email, you said:

> In the example above, there is nothing mutable about it. It is "read only=
" from a public contract point-of-view, we just can't mark it as a readonly=
 class.

In this most recent email, you said:

> The error you get when trying to modify the "get-only accessor" is `Error=
: Cannot assign to 'name' because it is a read-only property`
>
> Thus, readonly is implied by the get-only accessor, there's no need to sp=
ecify it directly.

Would you say this is how you are interpreting readonly? That it is a
contract to consumers of the class that they can read but cannot write
to it?

(including a snippet from an earlier email)

> I think an init hook is out of the question for 8.5, so I'm not even sure=
 it's worth discussing.

I don't agree that it's not worth discussing alternative solutions to
the problems the RFC authors intend to solve. I think it has been
expressed elsewhere, but I believe we should take the time to make the
best decisions for the language and not rush to add a controversial
feature.