Rename ZSchedule to Schedule

[adamgfraser]

Resolves #2054.

[mschuwalow]

You are fast :D

[regiskuckaertz]

Can I ask why the renaming? The Z prefix is kind of a theme to indicate that this is the most powerful version of a type, usually with the R, E, A trifecta.

[adamgfraser]

@regiskuckaertz I think the idea is that to use the "Z" nomenclature there should be sufficient use of the "non-Z" variant. So like for ZIO both IO[E, A] and ZIO[R, E, A] are very commonly used types so it makes sense to have type aliases to distinguish them. In contrast for Schedule with the recent changes the number of Schedule instances that don't use any environment type is quite small. So it makes sense to just have one type that does all the things you need to improve discoverability and avoid questions about "why doesn't schedule do X"?

[regiskuckaertz]

Gotcha. I think we should take a look at all the data structures perhaps to be consistent? I’m always flummoxed by the missing ZQueue constructors, All found in the Queue object instead.

[adamgfraser]

That's a great point. I think the principle should be that all types have corresponding objects and that the object should include all combinators that make sense for the constraints on the R and E parameters. So in particular ZQueue should have a companion object and it should include all the methods available in the Queue object plus possibly additional methods that deal with the R type. That would be a great first issue.

[jdegoes]

@regiskuckaertz 💯 That needs cleaning up.

@adamgfraser 👍

[jdegoes]

Looks great to me, the only thing I might do is add a ZSchedule type alias in the package object that is deprecated for 1.0.

[adamgfraser]

All set.