Closed yaymukund closed 4 years ago
Thanks for your comments. I'll update this soon ^^
I think this is ready for another review. I ended up changing things quite a bit to avoid allocations, but we now return an MpvNode
which owns the data and exposes the data via fn value(&self) -> MpvNodeValue<'_>
. I think this is zero allocations?
I was discussing this in the Rust community discord with moxian who helped design this (+ others! :), and also suggested possibly doing:
impl MpvNode {
fn ref_value(&self)->MpvNodeValueRef<'_> { ... }
fn value(&self)->MpvNodeValueOwned { ... }
}
I'm not entirely sure what that buys us, but thought I'd flag it up :)
Thanks for your review. After reading some other discussions about how to do this [1], I feel good about the approach we've taken in this PR.
[1] Related:
https://users.rust-lang.org/t/how-do-i-get-rid-of-this-pattern-of-extracting-a-value-from-an-enum/12555 https://stackoverflow.com/questions/34953711/unwrap-inner-type-when-enum-variant-is-known
Thanks for your work!
I thought I'd take a stab at implementing
MpvNode
. It's very rough but it seems to return the expected keys.Possible issues:
i32
andusize
~MpvStr<'a>
as the key to theHashMap
~Vec
/HashMap
(forArray
andMap
respectively)?~try_into
the correct approach here?~