Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128024
Precedence: bulk
MIME-Version: 1.0
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <9D5043B2-1589-4FD5-B289-6E98FB1177BE@nicksdot.dev> <16BD443D-A179-465D-84A0-6E3780F62D8E@gmail.com>
 <203C1BD7-E688-4E26-8EA6-EA5331525470@nicksdot.dev> <ad11aaa7-b2a8-423c-a29c-4200789e9406@mabe.berlin>
 <71E5E8FE-605D-4B32-8CCD-F7ECBD454E24@nicksdot.dev> <d9b452b9-25a0-4a04-a636-97694baedd14@mabe.berlin>
 <CA+NMNO07Kxj5+Ta05Aq4GQJzYK6eyb3C_gYpreEbwNGRZNyGTA@mail.gmail.com> <97C001B0-05DC-4797-A72A-F82E1A0AC30F@nicksdot.dev>
In-Reply-To: <97C001B0-05DC-4797-A72A-F82E1A0AC30F@nicksdot.dev>
Reply-To: erictnorris@gmail.com
Date: Sun, 13 Jul 2025 17:13:26 -0400
Message-ID: <CA+NMNO3GibbJNT=aBWvgOQso-1Mf4U2eUPhDBw_ur8t0cBCTuQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
To: Nick <php@nicksdot.dev>
Cc: Marc Bennewitz <marc@mabe.berlin>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: eric.t.norris@gmail.com (Eric Norris)

> Well, I don=E2=80=99t know. Everyone seems to think of init hooks (and th=
eir playing together with other hooks) differently.
> Some say this, some say that. That=E2=80=99s the exact issue. Want an exa=
mple?
>
> Eric just agreed with your code example which has a get hook AND init hoo=
k.
>
> ```
> class Test {
>     public int $seek {
>         init =3D> random_int(0, 100);   // called once on read if not ini=
tialized
>         get =3D> $this->seek + 100;
>         set =3D> $this->seek =3D $value + 100;
>     }
> }
> ```
>
> var_dump((new Test())->seek); // number between 100-200 OR 200-300 depend=
ing of the set hook be called once with the result of init as well.
>
> Or did I misunderstand it?
>
>
> I share the same understanding as you, Marc.
>
>
> But one mail before he answered to Larry:
>
> I think, at least for readonly, you couldn't have an init hook and a
> get hook, since the main objection here is to having get hooks on
> readonly properties at all. On normal properties, I think that'd be
> okay?
>
>
> So what is it? Get hook cool, or not? And how does an init hook work exac=
tly?
> How play all combinations together? And how with readonly?
> Why didn=E2=80=99t your example use readonly if we talk about readonly ho=
oks?

I believe you are attempting to point out a contradiction, but as far
as I can tell my two statements are consistent - his example did not
include readonly, and it makes sense to me as-is. My prior statement
to Larry is "I think, at least for readonly, you couldn't have an init
hook and a get hook". Again, his example is not readonly, so it's
consistent.

> Eric,
> why it wouldn=E2=80=99t be solved by an init hook? Well, because as you s=
aid, readonly get hooks would not be allowed in combination with init.
> Others apparently have different opinions. So will they, will they not?

I don't think others have different opinions, or at least I haven't
heard someone say that readonly get hooks should be allowed with init.

>
> I, however, want get/set on readonly properties. And that is what I propo=
sed here.
>
> An init hook is not part of this proposal and I am not planning to take t=
his on.
> This RFC, however, would not block anyone from creating their own RFC for=
 init hooks.
>
> B) Less Code
>
> Marc was talking about init, cache modifier and attributes in the same ti=
me.
> Claude initially wanted a cache modifier on each hook.
>
> I argue that =E2=80=9Creadonly implicates cached=E2=80=9D is very reasona=
ble here.
>
> Many, many opinions. Many, many options. All have their pros, and cons. A=
ll can be attacked, and defended. :)
>
> All I want is the below (less code; and no dealing with unrelated things =
just because I want to add hooks to a readonly class).
>
> ```php
>
> // I have a nice readonly class
> final readonly class Entry
>
> {
>     public function __construct(
>         public string $word,
>         public string $slug,
>     ) {}
> }
>
> // I simply want to add a hooked-property to that readonly class
> final readonly class Entry
>
> {
>     public function __construct(
>         public string $word,
>         public string $slug,
>         public array $terms {
>             set(array $value) =3D> array_map(static function (Term|array =
$term): Term {
>                 return $term instanceof Term ? $term : new Term(...$term)=
;
>             }, $value);
>             get =3D> $this->terms; // something, something
>         },
>     ) {}
> }
>

Your example might not need a "get" hook at all, if I understand
correctly? The default behavior would make sense here (and, it seems
for at least some part of the mailing list, is the *only* thing that
makes sense). You would need a "set" hook, but I don't think anyone is
objecting to that. If you'd like to propose "set" hooks in isolation,
it seems like it would pass.

> And for that, I believe, I provided a solution that is easy to reason abo=
ut (all details in previous mails), and allows everyone to achieve what the=
y want.

I appreciate that you are focused on solving a real-world problem, and
that you have implemented a solution that addresses the problem. I can
understand that it seems like it's in reach, and that this
conversation might feel like we're wasting time.

That said, I think a number of people have reservations with the
semantics of get hooks with readonly, and it's important that we take
the time to ensure this feature is one that makes sense to all
developers, and continues to push the language in the direction of
being more consistent and hard to misuse. In an earlier email, Larry
said, "`readonly` has always been misnamed; it should really be
`writeonce`, because that's all it is.  (Once again, this is likely
the most poorly designed feature we've added in many years.)". I hope
that I'm not misconstruing what he meant, but this makes it seem
especially prudent to avoid making additional mistakes with regard to
readonly.