Hi
Am 2026-05-09 15:14, schrieb Nicolas Grekas:
[…]
need the same adjustments. I don't think the stated benefits are
enough to warrant a full migration to a new method.
[…]
[…]
I now finally got around to reading your RFC in-depth and have also read
through the related GH-12695 issue to get the full picture.
I share Ilija's opinion in that this feels very much like a
“sledgehammer to crack a nut” approach to fix something that is
effectively the result of a userland implementation error in a feature
that nowadays has better replacements in many situations: Namely
forgetting to implement `__isset()` when `__get()` is implemented; and
not implementing a `null` check in `__isset()`. In fact the first issue
would not be solved by the proposal, since instead of forgetting to
implement `__isset()`, folks would just forget to implement
`__exists()`.
Given that the RFC can naturally only ship in a new PHP version and
users will not upgrade right-away, it will take years until folks can
actually rely on the updated behavior and they will need to maintain
their existing workarounds until then. Specifically for the “lazy
proxies” use case that also was the motivation for GH-12695 my
understanding is that this is already solved in a much cleaner way since
PHP 8.4 with native lazy objects. Why would I want to wait for PHP 8.6
to be the baseline, when the better solution is already available with
8.4? Similarly other “lazy initialization” use cases for individual
properties can already be solved with property hooks in a cleaner way.
That leaves the “JsonRecord” use case, where the magic method doesn't do
anything by itself either, since folks would need to manually call it to
make the “exists but is null” distinction. It could just be a regular
method there - as already done in userland collection classes that just
have explicit `->has()` and `->get()` methods instead of relying on
magic methods. These notably also allow for much cleaner access to
fields that are not valid PHP identifiers (e.g. fields starting with a
digit or fields containing spaces).
I would treat this as a documentation issue, where it's not clearly
specified that users are expected to implement a `null` check in
`__isset()` and that users are expected to also implement `__isset()`
when implementing `__get()`. Perhaps the latter could even be made a
warning. That leaves the issue in GH-12695 which could then be fixed as
a master-only bugfix. While this would still require folks to carry
their workarounds until they can rely on PHP 8.6, it would not make the
language any more complex by requiring folks to learn yet another
pattern.
Best regards
Tim Düsterhus
