Clean up FontRegistry's legacy collection handling - #4268
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request simplifies FontRegistry collection handling and font-record lifecycle management, including invalidation before listener notifications.
Changes:
- Replaces raw iterators and casts with typed collection APIs.
- Refactors font allocation and disposal responsibilities.
- Documents
cleanOnDisplayDisposal == falsebehavior. - Ensures replaced records are invalidated before notifications.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
FontRegistry still handles its collections the way it did before generics: explicit Iterators, casts through Object, and one variable reused for two unrelated values. It also lets FontRecord reach into the registry to retire its own fonts, mixing up who owns that decision. Simplify all of that, and write down what cleanOnDisplayDisposal == false already promises. No behavior change, other than put() now invalidating the replaced record entirely before notifying listeners rather than partly after, so the registry is consistent by the time they run. That listeners already see the new font when notified was untested, so a test now covers it. Assisted-by: Claude Opus 5 <noreply@anthropic.com>
5f1feb8 to
719d847
Compare
Test Results 858 files ±0 858 suites ±0 46m 1s ⏱️ - 4m 32s For more details on these errors, see this check. Results for commit 719d847. ± Comparison against base commit 5b3e6dd. |
fedejeanne
left a comment
fedejeanne
left a comment
There was a problem hiding this comment.
LGTM.
One small detail: the test is not a regression test so it passes with and without the other changes. This means that in this sentence (in the description):
No behaviour change, other than
put()now invalidating the replaced record entirely before notifying listeners rather than partly after, so the registry is consistent by the time they run.
... the change in put() remains untested.
That's correct. Thank you for pointing it out. The test was motivated by a different ordering of commands I had in an intermediate state of the change where the notification would have been sent for a wrong state. That's why I decided to pin the behavior with a test. It just shows that the pre-existing contract for The change to |
Pure simplification of long-standing awkwardness in
FontRegistry: collections handled as if generics did not exist (explicitIterators, casts throughObject), one variable ingetFontRecord()reused for two unrelated values, andFontRecordreaching into the registry to retire its own fonts rather than just reporting which ones it allocated.Also documents what
cleanOnDisplayDisposal == falsealready promises.No behaviour change, other than
put()now invalidating the replaced record entirely before notifying listeners rather than partly after, so the registry is consistent by the time they run.🤖 Generated with Claude Code