Added partialeq and eq derives

[celaus]

Fixes #61

[zslayton]

Hi, thanks for the PR.

Using a derive implementation of Eq/PartialEq means that two Schedules will only be equal if:

1. They represent the same set of datetimes
   AND
2. The source strings that were parsed to create the two Schedules are identical.

This might be a narrower definition of equality than we want, since you could have a schedule with a day field of SUN,MON,TUES,WED,THU,FRI,SAT and one with * and they'd represent the same conceptual schedule. Then again, I could see people reasonably arguing that the source string is part of Schedule equality.

Any thoughts on this?

[celaus]

Hmm true, that might be a too narrow definition.

I'd say if two instances represent the same datetimes and one has a source string and the other doesn't, they should still be equal. However I don't know cron syntax well enough to know if there is an example for the other way around as well, i.e. when the source strings are different but result in the same datetime representations...

Otherwise I'd say we compare source strings when available and datetime (only) for the rest?

I'm happy to implement whatever definition we agree on 😄

[zslayton]

Otherwise I'd say we compare source strings when available and datetime (only) for the rest?

The source string will always be available. (The source string is an Option in the struct as a bit of a workaround).

I'm inclined to say let's implement it using source string equality for now. Determining the equality of the cron schedule the string represents is much trickier, especially if the parser adds support for other syntaxes in the future.

Out of interest, what's your main use case for PartialEq and Eq?

[celaus]

I wanted to keep actions that run on the same schedule as a HashMap<Schedule, Vec<ExecuteOnSchedule> 😄
(I haven't worked on that particular project for a while)

[zslayton]

PartialEq and Eq implementations were added in PR #78.

[celaus]

Thank you everyone for pitching in!