Add missing UnorderedTraverse syntax#2148
Conversation
|
2.10 and 2.11 JVM failed the binary compatibility check. /cc @kailuowang |
|
You can't touch an existing trait, you have to have the |
|
Aah yes. I'll get that switched today. |
c8712bf to
a0f4152
Compare
Codecov Report
@@ Coverage Diff @@
## master #2148 +/- ##
==========================================
+ Coverage 94.64% 94.66% +0.01%
==========================================
Files 328 328
Lines 5548 5548
Branches 213 213
==========================================
+ Hits 5251 5252 +1
+ Misses 297 296 -1
Continue to review full report at Codecov.
|
| package syntax | ||
|
|
||
| trait TraverseSyntax extends Traverse.ToTraverseOps | ||
| trait TraverseSyntaxBinCompat0 extends UnorderedTraverse.ToUnorderedTraverseOps |
There was a problem hiding this comment.
shall we just name this one UnorderedTraverseSyntax since we dont' have one?
There was a problem hiding this comment.
We could. Is there any merit to keeping it as similar to Foldable/UnorderedFoldable (which doesn't have UnorderedFoldableSyntax)?
There was a problem hiding this comment.
Foldable/UnorderedFoldable is the unconventional one. I am referring to
trait FoldableSyntax extends Foldable.ToFoldableOps with UnorderedFoldable.ToUnorderedFoldableOps
The convention in Cats is that the syntax trait of a TC does NOT extend the syntax of its parent TC. For users to get the parent syntax, they have to either explicitly import the parent syntax, or using the all inclusive import.
So I think having an UnorderdTraverseSyntax trait is more conventional.
TBC, I am okay with cats.syntax.traverse the object extending the UnorderedTraverseSyntax, but it's not really conventional in Cats.
More conventional way would be adding a cats.syntax.unorderedTraverse and having it extending the UnorderedTraverseSyntax, along with making cats.syntax.all and cats.implicits to extends this trait as well as a work-around for keeping bin-compat.
There was a problem hiding this comment.
sorry about the bike shedding here. The main reason I am discussing more about it is that this would set up a precedence for working around bin compat breakage. although it's a bit atypical
|
also if this this not available in |
a0f4152 to
dfc8759
Compare
|
@andyscott how do you want to proceed with this PR? I'll be happy to make the rename changes for you if you want. |
|
Sorry for the delay. I can take care of it within the next day.
…On Mon, Jan 22, 2018 at 11:00 AM, Kai(luo) Wang ***@***.***> wrote:
@andyscott <https://github.com/andyscott> how do you want to proceed with
this PR? I'll be happy to make the rename changes for you if you want.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2148 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAS8W_tqMAW6BfBxBcLqWpI30zDGDVcWks5tNNqvgaJpZM4RaPzV>
.
|
dfc8759 to
87fbbb9
Compare
| with VectorSyntax | ||
| with WriterSyntax | ||
|
|
||
| trait AllSyntaxBinCompat0 |
There was a problem hiding this comment.
One more small thing, if we make this one abstract class (and maybe even have it extends AllSyntax) we can add more traits to it going forward.
There was a problem hiding this comment.
How about an abstract class AllSyntaxBinCompat extends AllSyntax with AllSyntaxBinCompat0?
There was a problem hiding this comment.
then what's the purpose of AllSyntaxBinCompat0? just as a versioning scheme?
There was a problem hiding this comment.
A downstream consumer can't mix in the abstract class but they could mix in AllSyntax and AllSyntaxBinCompat0 to get roughly the same effect. Without AllSyntaxBinCompat0, but then you'd have to remember that AllSyntax is missing UnorderedTraverse syntax. So it's versioning scheme to facilitate downstream use.
I'm not sure if it's worth it though. It's just an idea.
There was a problem hiding this comment.
I see. Makes sense to me
87fbbb9 to
af487e1
Compare
671c93f to
6375e01
Compare
Addresses #2147: