On Wed, Jan 14, 2026, at 2:00 PM, Claude Pache wrote:
>> Le 13 janv. 2026 à 22:30, Larry Garfield <[email protected]> a écrit :
>>
>> On Wed, Nov 5, 2025, at 5:24 PM, 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
>>
>> Hi folks.
>>
>> The holiday blackout period is over, and there's nothing else really to
>> discuss on this PR, so consider this an Intent to Vote notice for the
>> isReadable RFC.
>>
>> I'll call the vote later this week, baring any new serious constructive
>> feedback.
>>
>> --Larry Garfield
>
> Hi,
>
> The RFC says:
>
>> To use “my current scope,” the `static::class` construct is an easy way to
>> specify “whatever class this code is running in.”
>
> The code is running in `self::class` or `__CLASS__`, not in `static::class`.
Hm, good point. I've changed to to `self::class`, which I believe should only
be an Editorial change. (There's no change to the design, just to the
explanation, and it's arguably a typo.) I'll give it another day before
opening the vote just in case.
> As noted in the RFC, `isReadable()` will give unavoidable
> false-positives (returning `true` although attempt to read the property
> will error). But there is also a false-negative:
>
> ```php
> class C {
>
> function __construct(
> readonly private mixed $foo
> ) { }
>
> function __get($x) {
> if ($x === 'foo') {
> return $this->foo;
> }
> throw new Error('Undefined property '.$x);
> }
>
> function __isset($x) {
> if ($x === 'foo')
> return isset($this->foo); // not `true`, otherwise
> `isset(new C(null)->foo)` will return an incorrect result.
> }
> return false;
> }
> }
>
> $c = new C(null);
>
> // will return false, although it is readable
> var_dump(new ReflectionProperty($c, 'foo')->isReadable(null, $c));
> ```
>
> One could skip the `__isset()` check in order to avoid the
> false-negative, at the cost of more false-positives. I don’t know what
> is best, because I tend to avoid `__get()` like the plague anyway.
As discussed earlier in the thread and noted in the RFC, as long as hooks and
__get support arbitrary code, we can never guarantee no false positives or
negatives. Based on the earlier discussion, the current setup seems like the
best balance for the expected typical cases. So we'd rather stick with how it
is now.
--Larry Garfield
