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
