-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add a Request type #85
Comments
Getters would be a good idea here. |
@seanmonstar I'm happy to submit PRs for the three issues I opened, just wanted to get some input on them from you first. |
Ok, so we discussed the builder pattern in the libs blitz, and I think I have a clear picture on how this should probably all look. The builder should be updated according to #108. That struct should look something like this: pub struct RequestBuilder {
client: ClientRef,
request: Option<Request>,
} All of the builder methods will essentially be doing something conversions (like parsing into a That means the pub struct Request {
url: Url,
method: Method,
body: Option<Body>,
// ...
}
impl Request {
pub fn url(&self) -> &Url {
&self.url
}
pub fn set_url(&mut self, url: Url) {
self.url = url;
}
} Lastly, the builder would have 2 methods, Whatcha think of this proposal? |
That is pretty much what my PR does (except the builder refactoring). I just made the fields on If you assign a The only advantage would be the ability to restructure the underlying representation without a breaking change, which might valuable. |
Yes, we would rather have getter and setter methods, because it allows us to add fields to the struct without breaking |
I'll update the PR. I can also implement the builder changes, but might not have time until the weekend. |
I'd consider the builder changes a separate thing, so as to not block the |
Mhm, the API Guidlines don't offer an opinion regarding naming of getters. Should it be I personally prefer to drop the |
Also, this design does not account for the point I raised regarding extracting values from a request without cloning. For example, consider I want to add an additional header. Then I'd have to do get the headers, clone them, add my header and then set, which sucks. So... And maybe a |
Yes, getters don't tend to have the Also, I'd expect a Is there need to mutably get the body? |
This was done with #103. |
When building a client API based on reqwest, I would often want to modify or inspect the private fields on
RequestBuilder
, namely method, url, headers and body.Since they are private, you basically have to create your own builder and convert it, which is annoying.
What do you think about either making the fields public or providing getters/setters?
The text was updated successfully, but these errors were encountered: