Github user pwendell commented on the pull request:
https://github.com/apache/spark/pull/2216#issuecomment-57060715
Ah I see - I thought this was an abstract class instead of a trait being
modified in this patch.
This is not an error with the compatibility checker - it's a legitimate
break. Because of the way traits work in Scala, you cannot add a new method
even if it has a default implementation. It's more like an interface in that
regard. For this reason we usually try to avoid traits for public-facing things
that could be implemented as abstract classes.
However, it will only break if someone outside of Spark has written a class
that extends this trait directly or indirectly. @JoshRosen is the design here
that this trait should ever be used outside of Spark?
You can look on Slide 10 here to see why:
http://www.slideshare.net/mircodotta/managing-binary-compatibility-in-scala
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
