Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jomini::Value #148

Open
rlidwka opened this issue Dec 23, 2023 · 1 comment
Open

jomini::Value #148

rlidwka opened this issue Dec 23, 2023 · 1 comment

Comments

@rlidwka
Copy link

rlidwka commented Dec 23, 2023

It would be useful to have a structure that represents every possible value we can deserialize into. Example:

// here's deserializer into a generic Value
let value: HashMap<String, jomini::Value> = jomini::text::de::from_utf8_slice(r#"
    unquoted = 1234
    quoted = "567"
    operator > 0.5
    color = hsv { 0.3 0.4 0.5 }
    sequence = { 1 2 3 4 }
    map = { a = 1 b = 2 }
"#.as_bytes());

// and we can deserialize it into concrete type later
let unquoted = value.get("unquoted").unwrap();
assert_eq!(f32::deserialize(unquoted.clone()).unwrap(), 1234.0);

This is the similar idea to existing serde_value::Value, serde_json::Value, serde_yaml::Value and others.

  • it should losslessly keep any value from jomini deserializer (i.e. I can deserialize tape into it)
  • it should implement IntoDeserializer (i.e. I can deserialize it into any concrete value)
  • it should be a static type (owned)
  • it should implement Debug
  • it should give user some API to inspect the value (e.g. is it a token or a sequence)

There's ValueKind in jomini right now, but it's a borrowed type, it doesn't implement Debug, and it's not public API.

There's also generic serde_value::Value, but it is not lossless (loses quotes, operators, headers, etc.). And the code above fails with it in multiple ways (e.g. loses hsv header, loses > operator, and unquoted number is transformed into string and can't be parsed within assert statement later).

Why? I want to solve #138 in more generic way (rather than adding yet another _internal_jomini_property hack) + make low level syntax more accessible in general. Plus some visual inspection of the file contents via Debug.

@nickbabcock
Copy link
Contributor

Yeah an arbitrary lossless value would be nice. I can imagine it essentially being what ValueReader is today, except owned, which should check most everything off your list. I think it'd need to use a hack similar to _internal_jomini_property (or it can replace it) in order for the deserializer to properly handle it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants