::from_str but no ::to_str about cron

[rtyler]

I believe with #54 merged this can be closed

[bittrance]

I'm missing this as well. Would you accept PRs for impl Display for Schedule and/or a to_string() methods?

[zslayton]

Sure, I'd be happy to accept a PR for this. Just to clarify the scope:

• We'd add a new String field to the Schedule struct that stores the original input text that was parsed
• Both Display and to_string() would use that text for their implementations.

Is that what you had in mind?

I'd like to avoid trying to optimize the original text representation (for example: converting 1,2,3,4 to 1-4) since that's a much bigger can of worms.

[bittrance]

A possible implementation can be found at bittrance#1 . However, Schedule is a public struct which a user may construct manually, so we will only have "original" input if the schedule was created with the FromStr implementation. We don't have struct inheritance in Rust, so we can't trivially use different backing structs for FromStr and "raw" construction.

In this respect, having the various fields be able to recreate a string representation would better respect the current API.

Alternatively, you could expose Schedule::from as a constructor?

[zslayton]

However, Schedule is a public struct which a user may construct manually

I don't believe this is the case. While the struct itself is public, its member fields are not, which should preclude users from constructing new instances of it on their own. I've created a minimal code example demonstrating this. Let me know if I've misunderstood something.

[bittrance]

Indeed, this is the aspect of Rust visibility system that I never manage to internalize. Very well, then. Here's the PR #54 .

[zslayton]

Addressed by #54.