Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129598
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 12 Dec 2025 15:47:07 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <df8f68e9-5181-428a-ad01-b982ad4ec03c@app.fastmail.com>
In-Reply-To: 
 <AM8P250MB0170BF7A09A3DD4C3582EF98E2A6A@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
References: <e906b61e-b951-4eb4-aa0f-700e76dae6a9@app.fastmail.com>
 <AM8P250MB0170BF7A09A3DD4C3582EF98E2A6A@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Subject: Re: [PHP-DEV] [RFC] isReadable/isWriteable property reflection
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Dec 4, 2025, at 2:54 PM, Bob Weinand wrote:
> Hey Larry,
>
> On 6.11.2025 00:24:52, Larry Garfield wrote:
>> In other news, Ilija and I said a year ago that we'd take a swing at adding isReadable/isWriteable methods to ReflectionProperty.  Took a while, but here we are.  A strangely small RFC from us:
>>
>> https://wiki.php.net/rfc/isreadable-iswriteable
>
>
> Have you considered returning false on isReadable() and isWritable() for 
> methods, whose only statement is throwing? I.e. when a getter or setter 
> unconditionally throws without any other statements present, they are 
> not marked as readable or writable.
>
> Otherwise this essentially "punishes" providing better exceptions in a 
> getter or setter, and serves also cases where the LSP inheritance forces 
> presence of a getter/setter, but still shall not be allowed on the 
> specific instance.
>
>
> Thanks,
> Bob

Hi Bob.

We've discussed it privately, and feel it would be an unprecedented amount of magic behavior to introduce in what is otherwise a fairly small utility RFC.  Nowhere else does PHP do that kind of deep runtime introspection, and it's a rabbit hole much larger than we want to tackle.  It's also a non-trivial problem to solve.  For `throw new Exception();`, the opcodes look something like `V1 = NEW; DO_FCALL; THROW V1;.`  That's fairly straight-forward.  But what about:

* throw new Exception(getErrorMessage());
* throw new Exception(cond() ? 'Message 1' : 'Message 2');
* $message = getErrorMessage(); throw new Exception($message);
* if (cond()) { $message = 'Message 1'; } else { $message = 'Message 2'; } throw new Exception($message);

It's very hard to draw an arbitrary line to decide what is and what isn't allowed.  Handling these cases correctly would require a significant amount of complexity, and would still be incomplete.  If making small, seemingly benign changes can break the exception detection, that's arguably worse than no detection at all.

For now we'd rather just avoid that rabbit hole.

--Larry Garfield