Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127958
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 08 Jul 2025 10:10:33 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <cedce076-82de-4391-8a03-409690added9@app.fastmail.com>
In-Reply-To: <f4e4057b19a5ed9de7ad92215e78d58c@bastelstu.be>
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <CAMzRQTdDNsF_LPpNKUbVROTWjDbN2uDw-j2PrL3xp7qASA62GA@mail.gmail.com>
 <be533915-2b0d-460d-a5ea-76fe98fc4080@app.fastmail.com>
 <f4e4057b19a5ed9de7ad92215e78d58c@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jul 1, 2025, at 9:27 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2025-06-09 17:11, schrieb Larry Garfield:
>> I also fleshed out the __get mention with an example that shows what=20
>> you can already do today, and in fact could since 8.1 when readonly w=
as=20
>> introduced.  The hard guarantee of idempotency has never actually bee=
n=20
>> there.  (This also speaks to Claude's concern.)
>
> I don't think this really resolves Claude's concern. While it is=20
> certainly true that the guarantees do not currently hold, I don't=20
> believe this is strong enough of a reason not to provide for stronger=20
> guarantees in a *newly introduced feature*. The point of property hook=
s=20
> is for me that =E2=80=9Cdynamic properties=E2=80=9D are easier to reas=
on about compared=20
> to `__get()`. As a user when accessing a proper `readonly` property, I=20
> do not want to check if there is a property hook that might result in=20
> non-readonly behavior. As an engine developer I want to be able to=20
> optimize based on the `readonly`-ness of a property. Without such=20
> guarantees, the =E2=80=9Creadonly=E2=80=9D keyword does not provide va=
lue to me.

The only way to make the readonliness fully guaranteed would be to force=
 a readonly property to be cached;  (IE, the hook is only called at all =
if the property is uninitialized.)  But there's no obvious way to make t=
hat clear in the code that it's what's happening.

> I also believe the LazyProduct example to be broken, since lazy-loadin=
g=20
> individual properties might result in an object that is internally=20
> consistent if the database changes in-between.

That's true with any lazy-loading scenario.  The use of hooks doesn't ch=
ange that at all.

--Larry Garfield