Add an overload of FlatMapOps#>> that gives control on the evaluation…

[julienrf]

… strategy of the second action

[codecov-io]

Current coverage is 63.74%

Merging #492 into master will decrease coverage by -0.05% as of e9f63c9

@@            master    #492   diff @@
======================================
  Files          154     154       
  Stmts         2359    2361     +2
  Branches        66      66       
  Methods          0       0       
======================================
  Hit           1505    1505       
  Partial          0       0       
- Missed         854     856     +2

Review entire Coverage Diff as of e9f63c9

Powered by Codecov. Updated on successful CI builds.

[ceedubs]

On Gitter there was some discussion on whether to overload method names or use a consistent convention like an Eval suffix (such as pureEval) when an Eval alternative is provided. I like the idea of consistency, but that wouldn't work in the case of a symbolic operator like this one.

👍 from me, but I'm hoping @travisbrown can weigh in, because I remember he mentioned being in favor of not overloading.

[julienrf]

I’m fine with adding a suffix like Eval but we need to find a real name for that method :)

[travisbrown]

This SO answer is a good summary of some of the reasons to avoid overloading. I personally think this is more important for things like pure—some of the big problems with overloading (eta expansion, selective imports) just aren't as relevant for instance methods, and operators like this seem to be one of the places where they're easier to justify.

Even here though it still introduces some annoying questions. Is Eval.Unit >> Eval.now(Eval.True) an Eval[Eval[Boolean]] or just an Eval[Boolean]? What if you actually want it to be the former?

[tpolecat]

In this case I think the subtlety introduced when F is Eval is sufficient reason to disambiguate.

[ceedubs]

Thanks @travisbrown. You have me convinced that disambiguating might be a good idea.

[julienrf]

Hi,

I totally agree on the issues of overloading. I will be happy to remove my overload and to introduce two new methods, one that is an alias for the current >> and the other, suffixed with Eval, with the new signature … as soon as we will have found a nice name :)

What about discardAndThen? andAfter? Other suggestions?

[julienrf]

Hi guys,

I decided to go with andAfter since monads are essentially about control flow. Tell me what you think :)

[non]

Interesting. I think that's a good name, but it made me think of followedBy which might be better. What do you think?

[julienrf]

I’m fine with followedBy too. What do others think?

[julienrf]

I updated the PR to use followedBy.

[non]

This looks good to me. 👍

Did you want to create an overload for >> so you can choose to pass an Eval[F[B]] as well as an F[B]? If so, I would support adding it.

[julienrf]

No, I gave up the idea of overloading.

[non]

👍 from me then. Thanks for sticking with this! :)

[milessabin]

👍