Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128118
Precedence: bulk
MIME-Version: 1.0
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <9D5043B2-1589-4FD5-B289-6E98FB1177BE@nicksdot.dev> <CAPyj-LDVi3ZYQuzzJz7d+cHdU6C-cxYJUSkuzdyvWpw+sWuCsg@mail.gmail.com>
 <0856c89f-2000-448a-bbbf-c145a8699f6a@app.fastmail.com> <2641b8bc-6337-4b75-a5a3-93dee1b03796@bastelstu.be>
 <0d9a2968-26dd-43dd-9733-d2eb621ab9ec@app.fastmail.com>
In-Reply-To: <0d9a2968-26dd-43dd-9733-d2eb621ab9ec@app.fastmail.com>
Reply-To: erictnorris@gmail.com
Date: Fri, 18 Jul 2025 12:48:07 -0400
Message-ID: <CA+NMNO06L7J0sqRoBuX0Ts6jTbEF3BWC=qmYfHuN8yTDXrweDA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
To: Rob Landers <rob@bottled.codes>
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	Larry Garfield <larry@garfieldtech.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)

On Fri, Jul 18, 2025 at 12:01=E2=80=AFPM Rob Landers <rob@bottled.codes> wr=
ote:
>
>
>
> On Fri, Jul 18, 2025, at 17:25, Tim D=C3=BCsterhus wrote:
>
> Hi
>
> On 7/14/25 15:38, Larry Garfield wrote:
> > Thanks, Ilija.  You expressed my concerns as well.  And yes, in practic=
e, readonly classes over-reaching is the main use case; if you're marking i=
ndividual properties readonly, then just don't mark the one that has a hook=
 on it (use aviz if needed) and there's no issue.
>
> A readonly class is not just a convenience shortcut to mark each
> individual property as readonly. It has important semantics of its own,
> because it forces child classes to also be readonly. And even for final
> classes it communicates to the user that "I won't be adding non-readonly
> properties to the class".
>
>
> Wasn=E2=80=99t that the entire point of readonly classes? Because it was =
painful to write readonly for every property. Then if a property is readonl=
y, the inherited property is also readonly, so, by extension: a class exten=
ding a readonly class is also readonly.
>
> There=E2=80=99s no =E2=80=9Ccommunication=E2=80=9D here; just logic.
>
>
> Marking a class as readonly must therefore be a deliberate decision,
> since it affects the public API of your class and in turn also user
> expectations.
>
>
> Not really. I can remove the readonly designation and manually mark every=
 property as readonly. The behavior of the class doesn=E2=80=99t magically =
change. Or, at least, I hope it doesn=E2=80=99t.
>
>
> > Perhaps we're thinking about this the wrong way, though?  So far we've =
talked as though readonly makes the property write-once.  But... what if we=
 think of it as applying to the field, aka the backing value?
>
> I think of readonly from the view of the public API surface of an
> object. The property hooks RFC was very explicit in that property hooks
> are intended to be =E2=80=9Ctransparent to the user=E2=80=9D and can be a=
dded without
> breaking the public API. In other words: Whether or not a property is
> implemented using a hook should be considered an implementation detail
> and as a user of a class I do not care whether there is a backing value
> or not.
>
> > So readonly doesn't limit calling the get hook, or even the set hook, m=
ultiple times.  Only writing to the actual value in the object table.  That=
 gives the exact same set of guarantees that a getX()/setX() method would g=
ive.  The methods can be called any number of times, but the stored value c=
an only be written once.
>
> As a user of a class the "backing table" is mostly inaccessible to me
> when interacting with objects. It's only exposed via var_dump() and
> serialize(), the former of which is a debug functionality and the output
> of latter not something I must touch.
>
> > It would not guarantee $foo->bar =3D=3D=3D $foo->bar in all cases (thou=
gh that would likely hold in the 99% case in practice), but then, $foo->get=
Bar() =3D=3D=3D $foo->getBar() has never been guaranteed either.
>
> Properties and methods are something different. For methods there a
> reasonable expectation that *behavior* is associated with them, for
> properties there is not.
>
>
> Unless I missed something. Hooks are fancy methods? There is nothing intr=
insic about object properties. There is nothing that says two calls to the =
same property=E2=80=99s getters are going to result in the same values. The=
re is asynchronous php, declare ticks, etc. especially in the case of globa=
ls, there is no guarantee you even have the same object. At the end of the =
day, it is up to the programmer building that system / program to provide t=
hose guarantees=E2=80=94 not the language.

I do think that, without any additional information, it would be
reasonable to assume that `$foo->bar =3D=3D=3D $foo->bar`, i.e. there would
not be side-effects until you've called a method or written to the
object in some way. So I share Tim's opinion here, but I do agree that
with hooks available this is not actually a guarantee. You could
certainly have a `$foo->random_value` property and document that it
will be different each time you call it.

That said, once the programmer has added the readonly designation to a
property, I do think that something says that two calls to the same
property will result in the same values - the readonly designation. I
disagree with the point that it's not up to the language - the
language should provide an affordance for enforcing programmer intent,
and I see no reason to even have a readonly designation if we're going
to make it easily circumventable or otherwise just a "hint".

It seems that one common counterpoint to the "let's not make it
circumventable" argument is to point out that it's already
circumventable via __get. I agree with Claude that this is not a
justification for making it *easier* to circumvent. I would also like
to note that the original RFC
(https://wiki.php.net/rfc/readonly_properties_v2#unset) seems to allow
this behavior *for the purpose of lazy initialization*. With an `init`
hook, we'd have solved this problem, and could deprecate the `__get`
hack for `readonly` properties / classes.

Nicolas Grekas said "__get is certainly not legacy; removing it would
break many use cases without proper alternatives.", but note that I'm
only suggesting we could maybe deprecate __get for `readonly`
properties once we had an `init` hook - I'm not proposing deprecating
it generally. Without a counterexample, I don't think there would be
another reason for `__get` to work with `readonly` properties.