-
Couldn't load subscription status.
- Fork 1.4k
ZIO Test: Improve Ergonomics of Laws for Higher Kinded Types #3356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| /** | ||
| * Constructs a law from a pure function taking three parameters. | ||
| */ | ||
| abstract class Law3Function[-CapsF[_[-_]], -Caps[_]](label: String) extends Contravariant[CapsF, Caps, Any] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is always a function compose law, so maybe LawCompose or LawFunctionCompose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other possibility is to push it into ZIO Prelude as a class in the companion object of the associated type class (Covariant).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the renaming. Pushing it to ZIO Prelude is interesting. The disadvantage there would be that it is less ergonomic if someone else wants to implement their own law with the same shape, or even if we want to do so somewhere else in ZIO Prelude. But it does solve the problem that we don't necessarily know at the ZIO Test level the shape of all the laws we will want to test.
| /** | ||
| * Constructs a law from a pure function taking three parameters. | ||
| */ | ||
| abstract class Law3Function[-CapsF[_[_]], -Caps[_]](label: String) extends Invariant[CapsF, Caps, Any] { self => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For invariant, the likely form this law would take would be <=> instead of =>. So I'm not sure whether to put that in here or to defer it downstream. Thinking about it, nothing stops us from including these type classes in ZIO Prelude, so users can do things like new zio.prelude.Invaraint.ComposeLaw.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, for this one in particular we have to be quite careful in the way we generate the pair of functions so they form an equivalence relation.
|
Renamed covariant and contravariant versions to |
|
@adamgfraser Good to merge when conflicts are fixed! |
|
@jdegoes All set. |
|
@jdegoes Could I get a review on this? I added a |
|
@adamgfraser I like that direction (opening up the trait). If placed in the companion object of the corresponding type class, it should be easy for users to reuse these laws and know where to look for them. 👍 |
Minor improvements to support for laws for parameterized types based on initial experience working with them:
GenFfor standard types, so provides those.F[A]and two functionsA => BandB => Cfor contravariant and invariant types. We still have a little problem of needing more law constructors for different shapes of inputs, but the user experience is so much better when we provide them that I think we just try to do it for reasonable combinations that come up.