You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
@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.
@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.
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.
The text was updated successfully, but these errors were encountered: