Generalize to allow any "target" to be adapted for use with JsonPointer #4
Conversation
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
added 11 commits
December 21, 2023 17:40
DUH! Once the get methods were abstracted to a trait, serde_json could easily be supported! So this commit generalizes the mods and allows them to be a PR to the original repo - although there is a lot to do before actually merging.
* Reverse the Trait - it gets implemented on the target now, not on the pointer. * Update the doc * Update the tests to include simd * Lift to version 0.3.0 (breaks 0.2.0)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This PR basically does the following:
It is a breaking change from the original - the biggest difference being that the behaviour of getting
a Value from a container Value is now implemented on the value type, not the pointer, by virtue of
the new trait. However, ALL aspects of managing the JSON pointer itself are retained exactly as before
(except the update to 2021 semantics.
This of course, begs the question of whether, in fact, the JsonPointer type and its associated
artifacts and code should be in one crate, the new trait in a second, and implementations of that
trait in separate crates. We could then simple update THIS crate to have "legacy" behaviour via
a feature, and separate all the new stuff into the aforementioned crates. To discuss, I guess.
IT IS NOT YET READY! The following (at least) are required:
In the meantime, the functionality is available in a "stopgap" crate