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

Relationship between MediaType and MediaTypeBuf #13

Open
WhyNotHugo opened this issue Jun 27, 2023 · 4 comments
Open

Relationship between MediaType and MediaTypeBuf #13

WhyNotHugo opened this issue Jun 27, 2023 · 4 comments

Comments

@WhyNotHugo
Copy link

I tried to think of MediaType and MediaTypeBuf as analogous to Path and PathBuf or &str and String, but they don't seen to interact in the same way.

Notably, I can write a function that takes either &str or String:

fn func<S: AsRef<str>>(string: S) {
    println!("{}", string.as_ref());
}

Or a function that takes Path and PathBuf

fn func2<P: AsRef<Path>>(path: P) {
    println!("{:?}", path.as_ref());
}

But I don't quite see the relationship between MediaType and MediaTypeBuf. There don't seem to
be any methods to cast between one to the other. MediaType also doesn't have a to_str() or
similar function.

I'm trying to write a function where a mime type needs to be passed as parameter. Currently it
takes mime_type: MimeType, where MimeType: AsRef<[u8]>.

Do you have any insight for me on this case? Do you think that mediatype is a good fit here, or am I trying to fix square peg into round hole?

@WhyNotHugo
Copy link
Author

Looking closer at the implementation, I see that MediaType does actually have any reference to a string (or bytes) with the mime type; only separate bits which are non-continuous.

So I guess that there's no way to get a &str or &[u8] without more expensive shuffling.

@WhyNotHugo
Copy link
Author

OTOH, MediaTypeBuf cannot be constructed in a const context, so one can't have a few const variables for the commonly used types in a crate.

So using MediaTypeBuf is flexible with consumers for the unusual case, but more expensive for the common case.

I guess the real tricky part is the inability to cast between the two. Are they mostly incompatible implementations?

@picoHz
Copy link
Owner

picoHz commented Jul 2, 2023

@WhyNotHugo MediaTypeBuf and MediaType have very different inner structures so I could not implement AsRef. You can convert MediaTypeBuf to MediaType using MediaTypeBuf::to_ref.

@picoHz
Copy link
Owner

picoHz commented Jul 2, 2023

I made the two separate types for different situations because it is impossible to accomplish both const-constructibility and owned-type in a single type. You can cast between MediaTypeBuf and MediaType but it's not same as str and String.

let text_plain = MediaType::parse("text/plain; charset=UTF-8").unwrap();
let text_plain: MediaTypeBuf = text_plain.into();
let text_plain_ref: MediaType = text_plain.to_ref();
let text_plain_ref: MediaType = (&text_plain).into();

I'm trying to write a function where a mime type needs to be passed as parameter. Currently it
takes mime_type: MimeType, where MimeType: AsRef<[u8]>.

Do you have any insight for me on this case? Do you think that mediatype is a good fit here, or am I trying to fix square peg into round hole?

For the function parameter, I recommend to use MediaType. You can construct it from an arbitrary string using MediaType::parse.

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