Add CanopyJsonVisitor for generic tree browsing (JSON export) - #23
Merged
Conversation
Second of two planned HTTP endpoints (Canopy roadmap, HTTP Browse & Edit Handler): a CanopyVisitor that serialises any node (branch or leaf) to JSON, needed for the upcoming GET browse handler. Required a small prerequisite fix: acceptCanopy: never returned the visitor's result (missing ^), which the stream-based CanopyPrometheusVisitor never needed but a value-building visitor does. Also added the previously-missing acceptCanopy: for CanopyCell/CanopyDictionaryAccessor - both leaf types could not be visited at all before (doesNotUnderstand), since only CanopyAccessor/ CanopyBranchNode implemented it. Both changes are behaviour-preserving for existing visitors (Canopy-Metrics-Tests: 12/12 still green). Write-only accessors (no readSelector) serialise as JSON null rather than being omitted, unlike the Prometheus visitor - a browse client should still see the leaf exists. CanopyMetricGroup/CanopyMetricMap (Canopy-Metrics) are not yet covered by this visitor - out of scope here to avoid a Core->Metrics dependency; can be added later as a Canopy-Metrics extension method if the browse endpoint ever needs to expose metrics domains too. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
NeoJSON isn't loaded/available in the target image - STON already is and ships an explicit JSON-compatibility mode (STON toJsonString:) that produces byte-identical output to what NeoJSONWriter produced for all our cases (plain Dictionary/String/Number/Boolean/nil - no STON-specific class tags involved here). No test changes needed, Canopy-Core-Tests: 60/60 still green. Co-Authored-By: Claude Sonnet 5 <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.
Second of two planned HTTP endpoints (Canopy roadmap, HTTP Browse & Edit Handler): a CanopyVisitor that serialises any node (branch or leaf) to JSON, needed for the upcoming GET browse handler.
Required a small prerequisite fix: acceptCanopy: never returned the visitor's result (missing ^), which the stream-based CanopyPrometheusVisitor never needed but a value-building visitor does. Also added the previously-missing acceptCanopy: for CanopyCell/CanopyDictionaryAccessor - both leaf types could not be visited at all before (doesNotUnderstand), since only CanopyAccessor/ CanopyBranchNode implemented it. Both changes are behaviour-preserving for existing visitors (Canopy-Metrics-Tests: 12/12 still green).
Write-only accessors (no readSelector) serialise as JSON null rather than being omitted, unlike the Prometheus visitor - a browse client should still see the leaf exists.
CanopyMetricGroup/CanopyMetricMap (Canopy-Metrics) are not yet covered by this visitor - out of scope here to avoid a Core->Metrics dependency; can be added later as a Canopy-Metrics extension method if the browse endpoint ever needs to expose metrics domains too.