Finding a good / idiomatic name for derivable traits for a fallible conversion

Hello fellow Rustaceans!

I've been working on a crate for doing xml-rpc in Rust in a mostly declarative way (i.e. no manual handling of xml-rpc types at all):

GitHub - ironthree/dxr: declarative XML-RPC in Rust (docs)

The code is now pretty stable, there's extensive tests, it should be compliant with the xml-rpc spec (if you want to call it that), etc. In general, I'm very happy with how the project turned out.

However, one things I'm definitely not happy with is the name of two public traits.

For context: I have a Value (docs) type that unintentionally turned out to be kind of similar to serde_json::Value. There's a few types of values (integers, strings, floats, datetimes, bytes, arrays, structs, etc.), and they are represented by being variants of an internal Type enum.

The main benefit of dxr over other crates that implement xml-rpc is that dxr handles two types of type conversions transparently and automatically - both the conversion between Rust values / xml-rpc values and between xml-rpc values and their actual string representation as XML. The former is handled via two conversion traits (currently named ToDXR and FromDXR), the latter is an internal implementation detail which isn't even exposed to the user of the crate at all.

The ToDXR and FromDXR traits, their implementation for all relevant Rust types, and the ability to #[derive()] them for custom structs are what make the crate very ergonomic to use compared to other xml-rpc implementations in Rust. It's almost as easy as writing an xml-rpc client (or server!) in Python (except everything is type-safe!) :smile: (I think the examples and integration tests in the dxr crate give a good impression of that.)

However, I'm struggling to find better names for these two traits, and given that they're the center piece of the whole crate, the names should be good and obvious (why yes, I'm reading "Rust for Rustaceans" right now). And right now, I don't think the names are good:

  • The capitalization looks weird, to match the convention for abbreviations, it should be ToDxr and FromDxr.
  • The traits define a fallible conversion method (for example, string values could contain invalid XML escape sequences), and Rust's fallible conversion traits are named TryFrom and TryInto, while From and Into are traits for infallible conversions - so this does not match up with std and other Rust crates.
  • The traits are more like serde::{Serialize,Deserialize} than TryFrom and TryInto, i.e. they are derivable traits for a fallible conversion.
  • The traits convert things to / from a generic Value type, similar to the From<T> implementations of serde_json::Value, but fallible (and available for conversions in both directions).

I'm struggling to come up with any better names, though:

  • TryIntoValue / TryFromValue: would be consistent (they are fallible conversion traits), but this looks weird
  • MakeValue / UnmakeValue? humm ...
  • AssembleValue / DestructureValue? ...
  • Wrap / Unwrap? I'm only slightly joking.
  • Valuize / Devaluize? oh no, these are getting worse and worse.
  • ???, I'm out of ideas

There's also similar FromParams and ToParams traits (for converting Rust types / tuples to and from suitable xml-rpc method call parameter types), but these are not very visible to the user, so their bad names aren't as important. But if I can find a better name for these two as well, that would be even better ... (maybe Parametrize and Deparametrize? AssembleParams and DestructureParams? ... alright, I'll stop now.)

So, since I obviously can't make up my mind, I thought I'd ask here for help. Suggestions for better names (and of course, generic feedback for the code in the crate) are very welcome :smile:

I would lean toward those, maybe TryIntoDxr & TryFromDxr ? Or reuse serde's pattern, and let the namespace differentiate the two: dxr::Serialize/dxr::Deserialize ?

1 Like

Thanks for the suggestion! I actually thought about using dxr::De/Serialize, but that doesn't really match what it's doing (it doesn't do conversion to and from strings). Actually, serde::{Serialize,Deserialize} are already derived / implemented for my Value type (to handle the actual serialization to/from XML), so that would be kind of awkward.