Re: [RFC] isReadable/isWriteable property reflection

On Wed, Jan 14, 2026, at 2:00 PM, Claude Pache wrote: >> Le 13 janv. 2026 à 22:30, Larry Garfield <larry@garfieldtech.com> 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 �>$2��#{ > �^RI__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