Finish implementation of the contact field

[dbrgn]

http://spaceapi.net/documentation

[rnestler]

We have the contact field: https://github.com/coredump-ch/spaceapi-rs/blob/81d39efffcd4e5b4f4d04190ea20fa2dc7d5f3f8/src/status.rs#L46

I think this issue should be about this restriction:

You must define at least one which is in the list of allowed values of the issue_report_channels field.

At least one is difficult to verify at compile time.

[dbrgn]

No, that's in #7. Is the contact completely implemented otherwise?

[rnestler]

Oh its not complete.

[dbrgn]

Does someone have time to review this?

Btw, we should soon derive Eq for all structs, otherwise testing nested objects becomes awkward.

[dbrgn]

Btw, we should soon derive Eq for all structs, otherwise testing nested objects becomes awkward.

Actually we can only implement PartialEq, because some of the structs contain floats and floating point numbers don't fulfill the reflexive property.

[rnestler]

Just derive PartialEq then, at least for contact in this PR.

[rnestler]

This looks silly. Maybe we could use a builder here? Or at least a initializer method. We could also implement the Default trait and use it with update syntax:

Contact { irc: Value("irc://freenode.net/#coredump".into()), ..Default::default() }

[dbrgn]

Yeah, I already noted in the commit message that we need something to handle this :) But that's another PR.

[dbrgn]

Default also looks interesting, didn't know it yet. We could implement Absent as a default for Optional and then derive Default for all structs. Although that would mean that things like longitude and latitude would probably default to 0.0, which sucks :(

[dbrgn]

The PartialEq will be a separate PR. It's already on my laptop.

Is this good otherwise?

[rnestler]

If you don't want to bother with the initialization for now I would consider it good 👍