Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127633
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 09 Jun 2025 10:11:42 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <be533915-2b0d-460d-a5ea-76fe98fc4080@app.fastmail.com>
In-Reply-To: 
 <CAMzRQTdDNsF_LPpNKUbVROTWjDbN2uDw-j2PrL3xp7qASA62GA@mail.gmail.com>
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <CAMzRQTdDNsF_LPpNKUbVROTWjDbN2uDw-j2PrL3xp7qASA62GA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Jun 8, 2025, at 7:17 AM, Volker Dusch wrote:
> Hey Larry,
>
> Couple points from a first read and from trying to run the examples.
>
> a) From the "ProductFromDB" i get:
>
>> Fatal error: Uncaught TypeError: LazyProduct::$category::get(): Return value must be of type Category, none returned in ...
>
> I assume you're missing a return statement here? Or is there something 
> I'm missing?
>
> b) Minor wording gripe in the proposal section
>
>> On the other hand, there is no shortage of dumb things that people can do with PHP already. 
>
> While I don't disagree that PHP gives people a lot of freedom in how 
> they want to write their code, I find it a bit crude for an RFC to 
> phrase it like that. And the __get comparison is strong enough to stand 
> on its own.

Various typos have been fixed, and the code should be valid now.  The wording has also been adapted (though I am pretty sure "silly" has appeared in RFCs before).

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.)

> c) 
>
>> That is, we feel, an entirely reasonable use of hooks, and would allow for lazy-load behavior per-property on readonly classes.
>
> I might be misunderstanding the sentence here, but on-demand/Lazy 
> initialization of properties on readonly classes is already possible in 
> classic getter/setter classes.

If a class uses private properties and getX/setX methods, sure, those methods can be overridden to do whatever you want.  The whole point of hooks, though, is to NOT need those methods.  We want to enable someone to define a read-model easily, like the Product in the example.  That's all they should need to specify.  So, yes, technically it's "in a class that is designed with modern features" rather than having a long list of getX/setX methods just to give lazy-loading generated code a place to hook in.

> f) Date: 2024-07-10
>
> Is this correct? I know you created the page back then, but was there a 
> discussion already that I wasn't able to find?

Yes, this RFC was originally spun off from the hook-improvements RFC, as it needed more discussion while the other half of that RFC was uncontroversial.  I've added a link to the prior thread for reference.

--Larry Garfield