-------- Original message --------
From: Holly Schilling holly.a.schilling@outlook.com
Date: 14/07/2026 22:48 (GMT+07:00)
To: internals PHP internals@lists.php.net
Subject: Re: [PHP-DEV] Asymmetric Property Write Performance
This didn’t get much attention on the list, but Ilija was kind enough to review my Draft PR.
I think this is a good candidate to get into > 8.6 yet. I posted a formal RFC for it. I’ll give it a few days for anyone who wants to weigh in on if this should land in 8.6 or wait until the next release.
RFC: https://wiki.php.net/rfc/direction_aware_property_resolution
PR: https://github.com/php/php-src/pull/22709Holly
Hello Holly,
correct me if I'm wrong, but I don't see why that would be a RFC. (Small) internal changes with no change in userland don't go through the RFC process and are handled on GitHub instead. This should also target the supported version (8.4) instead of master.
Marc
correct me if I'm wrong, but I don't see why that would be a RFC. (Small) internal changes with no change in userland don't go through the RFC process and are handled on GitHub instead. This should also target the supported version (8.4) instead of master.
Honestly, I don’t know the norms for this kind of thing. This is a small change, but it involves an ABI breaking change. That was why I thought it should target a new release chain (8.6) rather than applying it to 8.4. If anyone wants to help me steward this out of being a draft, I would welcome the advice.
Holly
correct me if I'm wrong, but I don't see why that would be a RFC. (Small) internal changes with no change in userland don't go through the RFC process and are handled on GitHub instead. This should also target the supported version (8.4) instead of master.
Honestly, I don’t know the norms for this kind of thing. This is a small change, but it involves an ABI breaking change. That was why I thought it should target a new release chain (8.6) rather than applying it to 8.4. If anyone wants to help me steward this out of being a draft, I would welcome the advice.
Holly
For internal API breaking changes, it should definitely target master. Usually for stuff smaller changes in that purview, you shouldn't need an RFC unless requested.
Hi
correct me if I'm wrong, but I don't see why that would be a RFC.
(Small) internal changes with no change in userland don't go through
the RFC process and are handled on GitHub instead. This should also
target the supported version (8.4) instead of master.Honestly, I don’t know the norms for this kind of thing. This is a
small change, but it involves an ABI breaking change. That was why I
thought it should target a new release chain (8.6) rather than applying
it to 8.4. If anyone wants to help me steward this out of being a
draft, I would welcome the advice.
Even if there would be no change in internal API / ABI, performance
improvements are considered a feature and thus not applicable to PHP
8.4. Thus master / PHP 8.6 is the correct choice. With regard to an RFC,
please note that it’s less than 4 weeks until soft freeze, so it’s
impossible to meet the deadline with the minimum 2 weeks of discussion
and 2 weeks of vote. See also:
https://news-web.php.net/php.internals/131877
But I agree with the others that a pure performance improvement, without
an effect on the observable userland behavior (except for “it's faster
now”), very likely doesn't need an RFC - and probably not even a mailing
list discussion, unless there is disagreement on the PR itself.
Best regards
Tim Düsterhus