Skip to content

Refactor the way HTTP responses are generated from Results #282

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

Closed
alxiord opened this issue May 17, 2018 · 1 comment
Closed

Refactor the way HTTP responses are generated from Results #282

alxiord opened this issue May 17, 2018 · 1 comment
Labels
Good first issue Indicates a good issue for first-time contributors

Comments

@alxiord
Copy link

alxiord commented May 17, 2018

The following piece of code:

sender
    .send(Box<Something>)
    .map_err(|_| ())
    .expect("one-shot channel closed")

appears an awful lot throughout the code. We could make the code prettier by having a helper function which hides having to type these lines again and again. If we want to go to the next beauty level, we could implement the GenerateResponse trait for a Result, like this:

impl<V, E> GenerateResponse for Result<V, E> 
    where V: GenerateResponse,
               E: GenerateResponse {
    fn generate_response(&self) -> Response {
        return match self {
            Ok(v) => v.generate_response(),
            Err(e) => e.generate_response() 
        }
    }
}

This basically says that if both the Ok and the Err parts of a Result implement GenerateResponse, then the Result itself implements GenerateResponse, so we can send the Result variable through the channel without extracting the actual inner value first.

@andreeaflorescu andreeaflorescu added this to the Customer 2 Production milestone Jun 7, 2018
@acatangiu acatangiu modified the milestones: Customer 2 Production, Post v1.0 Jul 10, 2018
@acatangiu acatangiu added the Good first issue Indicates a good issue for first-time contributors label Jul 10, 2018
@andreeaflorescu
Copy link
Member

Not anymore 💃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good first issue Indicates a good issue for first-time contributors
Projects
None yet
Development

No branches or pull requests

3 participants