docs(spec): add spec 048 — lazy, trimmable control registration#466
Merged
Merged
Conversation
Follow-on to spec 047. Settles how V1 control registration should happen so it is automatic, lazy, and — the load-bearing requirement — does not defeat AOT trimming. Captures the discussion and resolution: - The pick-two-of-three tension (pure-data elements + automatic registration + trimmability can't coexist), grounded in the trimmer following static refs. - Rejected approaches (per-host RegisterHandler, element self-description/cctor, [ModuleInitializer], reflection discovery) each tied to the requirement they violate. - Resolution: factory-as-registration-link, with Pattern A (static-cctor factory holder for 3P controls) and Pattern B (generic Reg<E,C,H> scale pattern for the built-in catalog). - ControlRegistry contract, dispatch precedence, hot-path cost model, built-in migration (dismantle RegisterV1BuiltInHandlers, keep Factories aggregation-free), trim verification test, open questions, and phasing. Design only — no implementation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds spec 048, the design follow-on to spec 047. 047 made external control authoring possible (the V1 handler protocol + the
Reactor.External.TestControlproof). 048 settles how registration should happen so it is automatic, lazy, and — the load-bearing requirement — does not defeat AOT trimming.Design only — no implementation in this PR.
What it captures
The doc preserves the discussion and the resolution we converged on:
RegisterHandler, element self-description/cctor,[ModuleInitializer], and reflection discovery, each tied to the requirement it violates. (Notably:[ModuleInitializer]is a trimmer root that actively prevents trimming.)Reg<TElement, TControl, THandler>whose per-closed-generic-type statics register once (the ~50-control built-in catalog, noFactoriessplit).ControlRegistrycontract (idempotent, lock-free, roots nothing), dispatch precedence, the hot-path cost model (one predicted branch, zero alloc, zero lock), the built-in migration that dismantlesRegisterV1BuiltInHandlers, the "no type-level aggregation onFactories" invariant, and the CI trim verification test.Reg<>touches.Note for reviewers
The one item that needs a real ratification call is §12.1 — the duplicate-registration policy amends 047 §13 Q17 (global table → idempotent first-wins; explicit per-host API keeps the strict throw). That's a spec decision, not just an implementation detail.
🤖 Generated with Claude Code