Skip to content
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

Add ensureWith to Validated and Either (#1550) #1612

Merged
merged 12 commits into from
May 16, 2017

Conversation

LukaJCB
Copy link
Member

@LukaJCB LukaJCB commented Apr 18, 2017

Resolves #1550. Also looking for feedback on naming here, or maybe I should be adding an additional test apart from the doc test. Would be much appreciated :)

@kailuowang
Copy link
Contributor

I think additional tests would be nice for these logic.

@codecov-io
Copy link

codecov-io commented Apr 19, 2017

Codecov Report

Merging #1612 into master will increase coverage by 0.04%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1612      +/-   ##
==========================================
+ Coverage   93.38%   93.43%   +0.04%     
==========================================
  Files         241      241              
  Lines        4054     4068      +14     
  Branches      134      138       +4     
==========================================
+ Hits         3786     3801      +15     
+ Misses        268      267       -1
Impacted Files Coverage Δ
laws/src/main/scala/cats/laws/MonadErrorLaws.scala 100% <100%> (ø) ⬆️
...n/scala/cats/laws/discipline/MonadErrorTests.scala 100% <100%> (ø) ⬆️
core/src/main/scala/cats/syntax/monadError.scala 100% <100%> (ø) ⬆️
core/src/main/scala/cats/instances/either.scala 100% <100%> (+2.38%) ⬆️
core/src/main/scala/cats/MonadError.scala 100% <100%> (ø) ⬆️
core/src/main/scala/cats/syntax/either.scala 99.13% <100%> (+0.02%) ⬆️
core/src/main/scala/cats/data/Validated.scala 100% <100%> (ø) ⬆️
core/src/main/scala/cats/data/EitherT.scala 96.52% <100%> (+0.09%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cb949b8...a76d857. Read the comment docs.

@ceedubs
Copy link
Contributor

ceedubs commented Apr 25, 2017

It looks like ScalaDoc isn't happy about the $s in your message, because it's trying to interpret it as a ScalaDoc variable. You can change it to \$s or you can use traditional string concatenation instead of string interpolation to work around it.

@LukaJCB
Copy link
Member Author

LukaJCB commented Apr 27, 2017

Thank you @ceedubs! CI seems to be happy now :)

}
}

test("ensureWith should fail if predicate not satisfied") {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add this test to EitherTests as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@ceedubs
Copy link
Contributor

ceedubs commented Apr 28, 2017

Thanks @LukaJCB! This LGTM. The only thing that I'm not sure about is the name ensureWith. We have recoverWith defined in ApplicativeError, and the With there means something a little different. Having said that, I don't have a better name in mind and ultimately I'm okay with ensureWith if nobody has a better proposal.

It doesn't necessarily need to be done in this PR, but I think that ensureWith could also be added as a derived method alongside ensure in the MonadError type class.

@LukaJCB
Copy link
Member Author

LukaJCB commented Apr 28, 2017

Thanks for your feedback! :)
+1 for keeping it open to see if there's a better name! I can create another PR for the same method in MonadError soon! :)

@kailuowang
Copy link
Contributor

Given that we are close to 1.0.0-MF, I kind of prefer having the addition to MonadError and these in a single PR. I noticed that the MonadError instance for EitherT did not override the ensure method. So there are probably some optimizations can be done.
As for the name, I am probably the last person to give a better proposal but how about ensureOr? It's not more intuitive than ensureWith but at least it does not conflict with recoverWith.

@kailuowang kailuowang added this to the 1.0.0-MF milestone May 5, 2017
@kailuowang
Copy link
Contributor

This is going to be really useful. I constantly need this feature.
I would like to make the following suggestion.

  1. add the two new laws to MonadErrorLaws something like
def monadErrorEnsureConsistency[A](fa: F[A], e: E, p: A => Boolean): IsEq[F[A]] =
    F.ensure(fa)(e)(p) <-> F.flatMap(fa)(a => if (p(a)) F.pure(a) else F.raiseError(e))

def monadErrorEnsureOrConsistency[A](fa: F[A], e: A => E, p: A => Boolean): IsEq[F[A]] =
    F.ensure(fa)(e)(p) <-> F.flatMap(fa)(a => if (p(a)) F.pure(a) else F.raiseError(e(a)))
  1. override the ensureOr method in the MonadError instances for Either and EitherT , override the ensure method in the MonadError instance of EitherT, just like here

  2. remove the ensure and ensureOr tests in EitherTests and EitherTTests, since they will be covered by the law tests.

@LukaJCB
Copy link
Member Author

LukaJCB commented May 6, 2017

So implemented the changes, but removing the tests seems to have reduced the coverage, will investigate soon :D

@kailuowang
Copy link
Contributor

The newly added laws need to go into the tests in the discipline package.

@LukaJCB
Copy link
Member Author

LukaJCB commented May 6, 2017

Oops, yeah, that should've been obvious to me, fixed!

Copy link
Contributor

@ceedubs ceedubs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @LukaJCB! 👍 LGTM

@@ -63,6 +63,11 @@ final class EitherOps[A, B](val eab: Either[A, B]) extends AnyVal {
case Right(b) => if (f(b)) eab else Left(onFailure)
}

def ensureOr[AA >: A](onFailure: B => AA)(f: B => Boolean): Either[AA, B] = eab match {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this is following a precedent, but I find myself wondering if this Either syntax should really be providing syntax for methods that should already be available via type class syntax (in this case MonadError). Let's table that for a separate issue though.

@kailuowang
Copy link
Contributor

thanks so much @LukaJCB , sorry about the delay. LGTM. 👍
@peterneyens any other thoughts/feedback?

@peterneyens
Copy link
Collaborator

There seem to be some merge conflicts, otherwise this looks OK 👍 , thanks @LukaJCB !

I wonder if we maybe should implement ensure in terms of ensureOr that way just overriding ensureOr gives you a more efficient ensure as well.

@kailuowang
Copy link
Contributor

I took the liberty of resolving the conflict using github's merging too. Will merge if build green.

@kailuowang kailuowang merged commit 465b13a into typelevel:master May 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants