Split Schedule into source and a ScheduleFields struct. Also remove Option from Schedule::source about cron

[zslayton]

I'm in favor of this change. 👍

Lastly If you expose ScheduleFields (and add a getter to Schedule), it can be used for equality. This means that you can use the Schedule::source for a quick equality check of Schedules, and if you have a use case where you need to check for equivalence, you can manually choose to use the more "expensive" ScheduleFields equality check.

I'd like to offer this functionality, but rather than exposing ScheduleFields I'd have something like a pub fn ordinals_eq(&self, other: Schedule) -> bool method. This keeps the ScheduleFields type internal, allowing us to do other refactoring in the future if we need to. The Schedule type already allows you to access the TimeUnitSpec of each field. Thoughts?

[koenichiwa]

A use case to expose the fields would be that you can use them as a key for a map. See: #62 (comment)

[zslayton]

This may be a naming problem, but the distinction between a Schedule and a ScheduleFields isn't very useful to an end-user. The primary difference would be their definition of traits like PartialEq; there wouldn't be much reason for the user to request the ScheduleFields beyond that. They could achieve the same thing with a wrapper type, something like:

struct OrdinalsEqSchedule(Schedule);
//...impl PartialEq to use `ordinals_eq`

let my_schedule: Schedule = /*...*/;
let tasks: Vec<ExecuteOnSchedule> = /*...*/;
let mut tasks_to_execute: HashMap<OrdinalsEqSchedule, Vec<ExecuteOnSchedule>> = HashMap::new();
tasks_to_execute.insert(OrdinalsEqSchedule(my_schedule), tasks);

This makes me think that the comparatively expensive ordinals check should be Schedule's go-to definition of equality and that someone concerned with performance would instead do schedule1.expression() == schedule2.expression() or use schedule.expression() as their map key.

[koenichiwa]

Checking only on the TimeSpecs checks for equivalence though, not complete equality. The less expensive check on only the string checks for complete equality of two Schedules.

I can stand behind exposing a wrapper that checks equality on just the TimeSpecs, but I would keep Schedule's standard equality check as a check on just the string.

But maybe that's for another PR. I see you prefer not exposing ScheduleFields, and I can understand why🙂