Implement `Default` trait for `Client`, possibly others

[Byron]

To my mind, the standard way in Rust to instantiate something without any arguments is handled by the Default trait. Types implementing it can be aggregated, allowing the aggregator to simply use #[derive(Default)].

I think Client should implement it, and there might be other hyper-types which would need such an implementation as well.

Vec::default() might be a good starting point for this.

[seanmonstar]

Standard way is usually with some sort of 'new' method, which does exist.
However, it doesn't hurt to add a Default impl.

On Sat, Feb 28, 2015, 7:56 AM Sebastian Thiel notifications@github.com
wrote:

To my mind, the standard way in Rust to instantiate something without any
arguments is handled by the Default trait. Types implementing it can be
aggregated, allowing the aggregator to simply use #[derive(Default)].

I think Client should implement it, and there might be other hyper-types
which would need such an implementation as well.

Vec::default()
http://doc.rust-lang.org/collections/vec/struct.Vec.html#method.default
might be a good starting point for this.

—
Reply to this email directly or view it on GitHub
#351.

[Byron]

Thanks - from what I found so far is that APIs get more usable the more Traits they support. Especially if generic APIs want to use your types, more traits are better.
Having a Trait for the hyper::Client for example would make my code more readable. Currently it looks like this ...

pub struct DeviceFlow<C, NC> {
    client: C,
   [...]
    _m: PhantomData<NC>,
}

impl<C, NC> DeviceFlow<C, NC> 
    where   C: BorrowMut<hyper::Client<NC>>,
            NC: hyper::net::NetworkConnector {
    [...]
}

... and the problem is that I need to keep NC around to denominate the correct hyper client. Maybe there is another way, but I didn't find it :(.

[Byron]

General note: I just noticed that having a trait for a type makes it harder to use actually, as the trait needs to be imported as well to allow using any trait method. This is a general annoyance in Rust to me, as this should only be necessary if there is ambiguity. The more generic code is involved, uses get more convoluted too.