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

Refactor to support easier maintenance of binary compatibility. #1683

Closed
kailuowang opened this issue May 18, 2017 · 3 comments
Closed

Refactor to support easier maintenance of binary compatibility. #1683

kailuowang opened this issue May 18, 2017 · 3 comments

Comments

@kailuowang
Copy link
Contributor

Past 1.0.0-RC1 we will be more restricted by the requirement maintaining binary compatibility. So we should seek opportunities of changing the current code base in some ways that allow new changes without breaking compatibility.
One example I can think of is reducing the usage of traits. We have a companion objects extends traits for better code organization, but it makes adding methods to it without breaking binary compat harder (maybe it doesn't, I never tested).

There could be other ways but I don't have a lot of experience in this aspect. Any advice will be really appreciated.

@kailuowang kailuowang added this to the 1.0.0-RC1 milestone May 18, 2017
@ceedubs
Copy link
Contributor

ceedubs commented May 19, 2017

I have a bit of experience with managing binary compatibility. As you've mentioned, traits tend to be a liability (at least pre-2.12, which cats has to worry about for quite some time). Abstract classes should generally be preferred to traits if binary compatibility is a concern and multiple-inheritance isn't needed. There may be some places that we are using traits where we could be using abstract classes.

Unfortunately, I just don't think that there's anyway to provide the import cats.implicits._ and similar imports without using traits. There's a bit of discussion about this in #496.

#612 is an example of a PR that makes an attempt to manage binary compatibility (though I'm not sure how much it helps).

@kailuowang
Copy link
Contributor Author

@ceedubs I totally agree that we need traits to support all-in imports. For those, I think it's probably a good trade-off. I did notice cases where traits are used purely for better code organization like here. I think it might be a good idea to move all those inside the object.
A side note is that as you pointed out 2.12 makes this much better, but it's not clear to me how we can take advantage of it. Maybe at some point, we only promise binary compatibility on 2.12? I don't know.

@ceedubs
Copy link
Contributor

ceedubs commented May 19, 2017

@kailuowang yeah that's a good example of a place where I don't think that we are getting much benefit from a trait and it would probably be better to just put the methods directly on the object.

And yes, I also suspect that the only real way that we can take advantage of the 2.12 support for trait compatibility is once we are ready to drop 2.10 and 2.11 support. I think it will be quite some time before we are willing to drop 2.11 support at least.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants