Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127823
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 01 Jul 2025 16:27:15 +0200
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
In-Reply-To: <be533915-2b0d-460d-a5ea-76fe98fc4080@app.fastmail.com>
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <CAMzRQTdDNsF_LPpNKUbVROTWjDbN2uDw-j2PrL3xp7qASA62GA@mail.gmail.com>
 <be533915-2b0d-460d-a5ea-76fe98fc4080@app.fastmail.com>
Message-ID: <f4e4057b19a5ed9de7ad92215e78d58c@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-06-09 17:11, schrieb Larry Garfield:
> I also fleshed out the __get mention with an example that shows what 
> you can already do today, and in fact could since 8.1 when readonly was 
> introduced.  The hard guarantee of idempotency has never actually been 
> there.  (This also speaks to Claude's concern.)

I don't think this really resolves Claude's concern. While it is 
certainly true that the guarantees do not currently hold, I don't 
believe this is strong enough of a reason not to provide for stronger 
guarantees in a *newly introduced feature*. The point of property hooks 
is for me that “dynamic properties” are easier to reason about compared 
to `__get()`. As a user when accessing a proper `readonly` property, I 
do not want to check if there is a property hook that might result in 
non-readonly behavior. As an engine developer I want to be able to 
optimize based on the `readonly`-ness of a property. Without such 
guarantees, the “readonly” keyword does not provide value to me.

I also believe the LazyProduct example to be broken, since lazy-loading 
individual properties might result in an object that is internally 
consistent if the database changes in-between.

Best regards
Tim Düsterhus