Either .left, .right syntax

[edmundnoble]

No description provided.

[adelbertc]

👍

[codecov-io]

Current coverage is 92.20% (diff: 100%)

Merging #1454 into master will increase coverage by <.01%

@@             master      #1454   diff @@
==========================================
  Files           242        242          
  Lines          3615       3618     +3   
  Methods        3543       3550     +7   
  Messages          0          0          
  Branches         72         68     -4   
==========================================
+ Hits           3333       3336     +3   
  Misses          282        282          
  Partials          0          0          

Powered by Codecov. Last update 2fd55c5...2538b0e

[johnynek]

Seems fine, but I'm slightly concerned that Either.right and .left which exist and are a bit different from this. I wonder if more verbose, yet clearer might be better. .asLeft or .toLeft?

[edmundnoble]

@johnynek I can't see how Either.right and .left aren't the exact same as this, the same way Xor.right and .left were the same as their enriched syntax equivalents.

[johnynek]

Either instances already have right/left methods. The object does not. So,
if we do: x.right.right the first and second mean different things. Also we
can't nest an either inside an either using .right since the enrichment
won't be triggered on the second call.

To me, this is less clear than it needs to be. .toRight or .toLeft would
resolve the ambiguity I think.
On Sat, Nov 5, 2016 at 18:42 Edmund Noble notifications@github.com wrote:

@johnynek https://github.com/johnynek I can't see how Either.right and
.left aren't the exact same as this, the same way Xor.right and .left
were the same as their enriched syntax equivalents.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#1454 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEJdkbM2jCech1LhinBljfA3EArB5fAks5q7VrIgaJpZM4KqdKE
.

[kailuowang]

Let's make this private val obj: A , otherwise everybody will have an obj that point to itself.

[edmundnoble]

I'll do it to all the ops classes in here, for consistency.

[edmundnoble]

@kailuowang I checked and it looks like we don't use private vals in constructors for ops classes elsewhere in cats. Should I perhaps keep it not private for now for consistency, then submit a PR making all of them private?

[kailuowang]

But this is the only one that applies to all types. So I would favor a bit inconsistency over having a surprising obj on all types.

[edmundnoble]

This isn't the only one that applies to all types, see OptionIdOps. Everything has an a member already.

[kailuowang]

Ah, don't know how I missed that. I will submit a PR to fix OptionIdOps as soon as I get back to my laptop. Thanks for pointing it out. I still don't think being consistent with previous mistakes provides much value here.

[edmundnoble]

You will also have to fix ApplicativeIdOps, ValidatedIdSyntax, and WriterIdSyntax. I don't think e.g. attaching an oa member to every Option[A] is particularly helpful either; are you sure we shouldn't make them all private?

[edmundnoble]

@kailuowang I have a PR (#1456) making the ops classes consistent in this regard.
Edit: You cannot make the val param of a value class private in 2.10. We're going to have to keep them all public.

[kailuowang]

Thanks!

[edmundnoble]

@johnynek Sorry for the miscommunication, I was referring to the Either.right and .left methods we enriched on to the Either companion object and not the projection methods defined on the values themselves. From that angle, I can certainly see where you're coming from and think asLeft and asRight could work.

Edit: The reason I favor asLeft and asRight over toLeft and toRight is that those two are already supplied on scala.Option to work with Either, and they do something different.

[johnynek]

👍 Looks good to me!

[kailuowang]

👍
Thanks very much!