Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128114
Message-ID: <2641b8bc-6337-4b75-a5a3-93dee1b03796@bastelstu.be>
Date: Fri, 18 Jul 2025 17:25:12 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
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>
Content-Language: en-US
In-Reply-To: <0856c89f-2000-448a-bbbf-c145a8699f6a@app.fastmail.com>
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

On 7/14/25 15:38, Larry Garfield wrote:
> Thanks, Ilija.  You expressed my concerns as well.  And yes, in practice, readonly classes over-reaching is the main use case; if you're marking individual 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".

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.

> 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 “transparent to the user” and can be added 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, multiple 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 give.  The methods can be called any number of times, but the stored value can 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 === $foo->bar in all cases (though that would likely hold in the 99% case in practice), but then, $foo->getBar() === $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.

A 99% case is not sufficient for me to rely on when there's explicit 
communication by the class author that I may rely on properties not 
suddenly changing.

Best regards
Tim Düsterhus