Ion Element/Value API #114
Labels
enhancement
New feature or request
Comments
|
There's some interesting test code from Almann along these lines in the |
almann
added a commit
that referenced
this issue
Mar 23, 2021
Provides an _borrowed_/_owned_ implementations of the traits in the `value` module. The borrowed implementation is tied to a lifetime for string/binary data (but potentially more in the future). The owned implementation is completely self contained. * Defines `SymbolToken` and `ImportSource` traits that is the basis for full symbol/field name/annotation support in `ion-rs`, but also is required for the `Element` trait. * APIs that return `Iterator` types currently use a `Box` to avoid the need for generic associated types (GAT). * Captures the variance of integers in Ion with the `IntAccess` trait and the `AnyInt` enum. * Currently implements the `Struct` trait via `Vec` of tuples, which will have to be refactored for O(N) access but is suitable for the iterator APIS. Starts to address #114, but is not nearly complete. This commit is to provide the initial structure of this API for collaborative development, and to get early review.
almann
added a commit
that referenced
this issue
Mar 26, 2021
Provides an _borrowed_/_owned_ implementations of the traits in the `value` module. The borrowed implementation is tied to a lifetime for string/binary data (but potentially more in the future). The owned implementation is completely self contained. * Defines `SymbolToken` and `ImportSource` traits that is the basis for full symbol/field name/annotation support in `ion-rs`, but also is required for the `Element` trait. * APIs that return `Iterator` types currently use a `Box` to avoid the need for generic associated types (GAT). * Captures the variance of integers in Ion with the `IntAccess` trait and the `AnyInt` enum. * Currently implements the `Struct` trait via `Vec` of tuples, which will have to be refactored for O(N) access but is suitable for the iterator APIS. Starts to address #114, but is not nearly complete. This commit is to provide the initial structure of this API for collaborative development, and to get early review.
This was referenced Mar 26, 2021
almann
pushed a commit
that referenced
this issue
Mar 30, 2021
* Adds `Sequence` methods: `get`, `len`, `is_empty`. * Adds `Struct` methods: `get`, `get_all`. * `Struct` uses a `HashMap` with `(key, values) -> (String, Vec<(SymbolToken, Element)>)` as well as a `Vec<(Symboltoken, Element)>` to store fields with no text `SymbolToken` Rebases #132 and related to #114.
This was referenced Mar 31, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello, this is a request for enhancing/extending the functionality provided to Rust Ion users.
The IonJava and IonElement libraries provide useful abstractions over Ion readers and writers (which themselves are very useful).
As a user of the
ion-rscrates, I find myself wanting a API similar to those found in the Java libraries (above) or theserde-rs/jsoncrate.The reason is simple: to make sensible code, I must build structures (
enumeven) around theion-rs/*functions and constants. Then I must also consider all of the other low-level concerns of (lazily) materializing, (avoiding) clones of effectively immutable data to satisfy the borrow checker, etc. etc.I suspect can and should be "solved once" as in the Java prior art.
Thanks,
Chuck
The text was updated successfully, but these errors were encountered: