Switch from stateless to stateful Clock

[PTaylor-us]

Currently, the Clock trait is composed of only associated functions. Per #21 (comment), they need to be changed to methods. Specifically, now() needs to take &mut self.

[PTaylor-us]

What happens when more than one instance use the same hardware? Perhaps this can be prevented by consuming the resource upon instantiation.

[eldruin]

Looks good to me so far. You would not be able to have more than one mutable reference at a time to a Clock implementer so I think preventing multiple instances is not an issue.
The problem with consuming valuable resources is that you need to handle how to return them again. Specially when adding fallible interactions this can become a bit messy. c.f. 2. at #21 (comment)

[PTaylor-us]

Looks good to me so far. You would not be able to have more than one mutable reference at a time to a Clock implementer so I think preventing multiple instances is not an issue.
The problem with consuming valuable resources is that you need to handle how to return them again. Specially when adding fallible interactions this can become a bit messy. c.f. 2. at #21 (comment)

Correct me if I'm wrong, but I believe that is entirely an implementer issue and not something the trait needs to handle.

[PTaylor-us]

So I think this is good to merge into the v0.6 branch to be joined shortly with #21 and #29 . Do you agree?

[eldruin]

The problem with consuming valuable resources is that you need to handle how to return them again. Specially when adding fallible interactions this can become a bit messy. c.f. 2. at #21 (comment)

Correct me if I'm wrong, but I believe that is entirely an implementer issue and not something the trait needs to handle.

That is true. I was only trying to comment on your remark about resource consumption upon instantiation.

So I think this is good to merge into the v0.6 branch to be joined shortly with #21 and #29 . Do you agree?

Yes!