Hi On 11/7/25 20:12, Larry Garfield wrote:
(The counter argument, I suppose, is that this is hardly going to be a super-common routine to call so ergonomics don't matter.)
Yes. I expect this to mostly be useful deep within frameworks or specialized libraries. The type of code where these functions are likely to be used are very likely to be functions with an above-average complexity and having explicit code there will help keep the complexity low. Also it's not like `static::class` is particularly complicated to use.
One issue I'm seeing with the “magic context” logic is that the code will suddenly break when the call to `->isReadable()` is moved into a helper function. Particularly when you consider the __get() use case that I mentioned below: Folks that are interested in wanting to learn whether there's a property that is actually readable *or* a magic getter might want to put this combined logic into a helper - and then the implicit scope will no longer work.
stack-inspection isn't new. `Closure::getCurrent()` is the most recent example, so we don't think it's especially problematic.
The difference is that `Closure::getCurrent()` is a single-purpose function that is explicitly defined to operate on the current scope. It specifically throws an Error when misused. `->isReadable()` OTOH will silently misbehave.
AFAICT it would also be the first reflection function that has dynamic behavior.
If there's a preference for avoiding magic strings, it would be easy enough to use an enum instead. Something like:
My issue is not primarily with the “magic string”, but with the quite significant behavioral difference depending on the parameter value.
Best regards Tim Düsterhus
