REST API: Remove a redundant private property in WP_REST_Template_Autosaves_Controller. - #13041
Conversation
…osaves_Controller. `WP_REST_Template_Autosaves_Controller` declared its own private `$parent_post_type` and assigned it in the constructor immediately after calling `parent::__construct()`, which already performs the same assignment. Because both declarations are private, PHP allocates a separate slot for each, and the subclass copy was never read by any method. The sibling `WP_REST_Template_Revisions_Controller`, added in the same changeset, needs its copy: `get_parent()` reads `$this->parent_post_type` from the subclass, where the ancestor's private property is out of scope. No method on the autosaves controller does the same, so the property and its assignment are removed and the surrounding alignment restored. This was the only `property.onlyWritten` occurrence, so the baseline is emptied. The file is removed along with its `includes` entry in `phpstan.neon.dist`. Props CallumBW95. See #65817.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
1 participant
WP_REST_Template_Autosaves_Controllerdeclares its own private$parent_post_typeand assigns it in the constructor on the line afterparent::__construct(), which already performs that assignment:WP_REST_Autosaves_Controllerdeclares$parent_post_typeprivately as well, so PHP allocates a separate slot for each declaration rather than reusing one. Nothing on the subclass ever reads its copy, which is the singleproperty.onlyWrittenoccurrence in the baseline:Removing the declaration and the assignment leaves the two remaining assignments in that block over-aligned, so they are realigned to match.
Why this cannot change behaviour
Private properties with the same name in a class and its subclass do not share storage, and a method inherited from the ancestor always reads the ancestor's slot regardless of whether the subclass declares its own. That is worth demonstrating rather than asserting:
Bis the current shape andCis the shape after this change. The inheritedreadIt()returns the same value either way, because it readsA's slot in both cases. The subclass copy is pure overhead.The property is
private, so it has no public or extender-facing surface and removing it carries no backward compatibility cost, despite the@since 6.4.0on its docblock.How it got there
This class and
WP_REST_Template_Revisions_Controllerwere added together in [56819] (2023-10-10), which introduced both files in one go at 276 and 297 lines. The two constructors are near-copies of one another.The revisions sibling genuinely needs its shadowed copy.
WP_REST_Template_Revisions_Controller::get_parent()reads$this->parent_post_typefrom the subclass, and the ancestor's copy is private and therefore out of scope there, so without the redeclaration that read would fail:No method on the autosaves controller does anything equivalent. The property is load-bearing in one of the pair and vestigial in the other, which is consistent with the two constructors having been written from the same starting point. Neither the declaration nor the assignment has been touched since [56819].
One thing I left alone
WP_REST_Autosaves_Controller::$parent_post_type, the ancestor's own copy, also looks like it is written and never read. Its own methods do not reference it, and the reads atWP_REST_Revisions_Controllerlines 164 and 826 resolve to that class's slot rather than this one.PHPStan does not report it, including when the baselines are suppressed during regeneration, so I have not touched it. I cannot account for why the two are treated differently and did not want to act on a claim I could not substantiate. Flagging it in case it is of interest.
Testing instructions
trunk,npm run typecheck:phpreports[OK] No errors, because the occurrence is baselined.tests/phpstan/baselines/property.onlyWritten.neonand itsincludesentry, then run it again. PHPStan reportsProperty WP_REST_Template_Autosaves_Controller::$parent_post_type is never read, only written.npm run typecheck:phpreports[OK] No errorswith the baseline gone and nothing new elsewhere. The baseline directory goes from 70 files to 69.composer lintis clean on the changed file, including the realigned assignments.npm run test:php -- --filter 'Autosave|Template'gives 779 tests, 2594 assertions, 5 skipped, exit 0.tests/phpunit/tests/rest-api/wpRestTemplateAutosavesController.phpwas added alongside the class in [56819] and has 23 test methods, all of which construct the controller.Trac ticket: https://core.trac.wordpress.org/ticket/65817
Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: tracing the property through the four-class hierarchy to establish which copies are read,
git logarchaeology identifying [56819] as the origin, constructing the private-shadowing demonstration above, and drafting this description. The diagnosis, the decision to leave the ancestor's copy alone, the baseline regeneration, and verification against full PHPStan, PHPCS and PHPUnit runs were reviewed and confirmed by me in a local development environment.