# Asymmetric Property Write Performance - Thread: https://externals.io/message/131918 - Original archive: https://news-web.php.net/php.internals/131918 - Started by Marc Henderkes on 2026-07-14T16:59:23+00:00 - Messages: 4 - RFC: Direction Aware Property Resolution (Implemented (PHP 8.6)) — https://externals.io/rfc/direction_aware_property_resolution.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #131918 — Marc Henderkes — 2026-07-14T16:59:23+00:00 URL: https://externals.io/message/131918#131918 -------- Original message -------- From: Holly Schilling Date: 14/07/2026 22:48 (GMT+07:00) To: internals PHP 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/22709 > > Holly 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 --- ## #131919 — Holly Schilling — 2026-07-14T17:11:46+00:00 URL: https://externals.io/message/131918#131919 · In reply to: #131918 > 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 --- ## #131920 — Calvin Buckley — 2026-07-14T17:32:49+00:00 URL: https://externals.io/message/131918#131920 · In reply to: #131919 > > > […] > > 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. --- ## #131934 — tim@bastelstu.be — 2026-07-15T12:25:14+00:00 URL: https://externals.io/message/131918#131934 · In reply to: #131919 Hi > > […] > > 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