Let a generator that cannot ship here register itself - #157
Merged
Conversation
SchemaGenerator's table of generators was a fixed private dictionary, which assumes every generator can live in this project. Not every one can: this library publishes net8.0, and the C++ generator is built on an AST that ships no net8.0 assembly, so it has to live somewhere with a higher framework floor. Register is what lets it, and still be found by the language a schema names. IsRegistered is the other half: a host that has just registered its own generators can ask whether a schema's language will resolve before running anything, rather than discovering it in a generation result. Registration replaces rather than duplicates, so a host may override a built-in generator, and a generator naming no language is refused outright - it could never be found again, so an entry under an empty key would only fail later and further away. The table is process-wide and unsynchronised, meant to be filled once while a program starts. The remarks say so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AhoPJ5AbxP8QEBNxPQYEPk
MSTEST0037: comparing a count to zero says less than asserting emptiness, and Assert.AreEqual(0, ...) reports "expected 0, was 2" where Assert.IsEmpty names what it found. The message follows the convention the rest of the suite already uses for a validation assertion - joining the issues, so a failure says which rule fired rather than only that one did. Reported by SonarCloud on #156, which had already merged. The same shape appears throughout the suite and predates that change; only the new line is touched here, since a sweep would be a large diff for no behaviour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AhoPJ5AbxP8QEBNxPQYEPk
|
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
2 participants
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.
Two things, one of which #156 should have carried and narrowly missed.
The generator table is no longer fixed
SchemaGenerator's table of generators was a private dictionary built once, which assumes every generator can live in this project. Not every one can: this library publishesnet8.0, and the C++ generator being written next is built on an AST that ships nonet8.0assembly, so it has to live somewhere with a higher framework floor.Registerlets one do that and still be found by the language a schema names.IsRegisteredis the other half, so a host that has just registered its own generators can ask whether a schema's language will resolve before running anything, rather than discovering it in a generation result.Registration replaces rather than duplicates, so a host may override a built-in generator, and a generator naming no language is refused outright — it could never be found again, so an entry under an empty key would only fail later and further away. The table is process-wide and unsynchronised, meant to be filled once while a program starts; the remarks say so.
This commit was pushed to #156's branch a few seconds after that PR merged, so it never made it in. Recovered here rather than rewritten.
One assertion, from #156's Sonar analysis
MSTEST0037onVectorElementTypeTests.ANumericComponentValidates: comparing a count to zero says less than asserting emptiness, andAssert.AreEqual(0, …)reports "expected 0, was 2" whereAssert.IsEmptynames what it found. The message now joins the issues, following the convention the rest of the suite already uses for a validation assertion, so a failure says which rule fired.The same shape appears throughout the suite and predates #156 — Sonar only reports it on new code. Only the new line is touched; a sweep would be a large diff for no behaviour.
Testing
376 tests pass, 0 warnings, 0 errors. Seven of those are new in
GeneratorRegistryTests, covering registration, case-insensitive lookup, replacement, that the built-in generator is still there, and both refusals.🤖 Generated with Claude Code
https://claude.ai/code/session_01AhoPJ5AbxP8QEBNxPQYEPk
Generated by Claude Code