Re: [RFC] isReadable/isWriteable property reflection
| From: | Larry Garfield | Date: | Fri, 12 Dec 2025 21:47:07 +0000 |
| Subject: | Re: [RFC] isReadable/isWriteable property reflection | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-129598@lists.php.net to get a copy of this message | ||
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