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 OptionT.liftF and update related docs and tests. Close issue #659 #667

Merged
merged 3 commits into from
Nov 17, 2015

Conversation

lambdista
Copy link
Contributor

No description provided.

@codecov-io
Copy link

Current coverage is 80.97%

Merging #667 into master will increase coverage by +0.01% as of 5ef2fd9

@@            master    #667   diff @@
======================================
  Files          159     159       
  Stmts         2122    2123     +1
  Branches        72      72       
  Methods          0       0       
======================================
+ Hit           1718    1719     +1
  Partial          0       0       
  Missed         404     404       

Review entire Coverage Diff as of 5ef2fd9

Powered by Codecov. Updated on successful CI builds.

* Lifts the `F[A]` Functor into an `OptionT[F, A]`.
*
*/
def liftF[F[_], A](fa: F[A])(implicit F: Functor[F]): OptionT[F, A] = OptionT(F.map(fa)(Option(_)))
Copy link
Contributor

Choose a reason for hiding this comment

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

This may not really be something to worry about, but I'm thinking that maybe this should use Some(_) instead of Option(_). The Option.apply method has logic to turn null into None. In Cats we are generally assuming that people aren't passing around null. But if for some reason they really want to lift a null value into the OptionT structure, I don't think we should prevent them from doing that here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I used Option(_) to prevent null and getting None instead of Some(null) in that case, but if you confirm we should not prevent them from doing that I'll change it to Some(_).

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that it should be consistent with our Applicative[Option].pure implementation, which uses Some: https://github.com/non/cats/blob/master/core/src/main/scala/cats/std/option.scala#L14. So yeah, I think we should change this here. I don't think we should conflate the issues of lifting and de-nulling.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I totally agree! I'll change it to Some(_). Thank you.

@ceedubs
Copy link
Contributor

ceedubs commented Nov 17, 2015

Thanks, @lambdista! In general, this looks great. I left a couple very minor comments.

@lambdista
Copy link
Contributor Author

Thank you @ceedubs for your support!

@ceedubs
Copy link
Contributor

ceedubs commented Nov 17, 2015

👍 (assuming the build passes). Thanks again!

@lambdista
Copy link
Contributor Author

Thank you! 👍

@non
Copy link
Contributor

non commented Nov 17, 2015

👍 Good work! Thanks! 🐈

non added a commit that referenced this pull request Nov 17, 2015
add OptionT.liftF and update related docs and tests. Close issue #659
@non non merged commit 246512e into typelevel:master Nov 17, 2015
@lambdista lambdista deleted the optiont-liftf branch November 17, 2015 15:25
@ceedubs ceedubs mentioned this pull request Nov 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants