srowen commented on a change in pull request #27978: [SPARK-31127][ML]
Implement abstract Selector
URL: https://github.com/apache/spark/pull/27978#discussion_r396489569
##########
File path: project/MimaExcludes.scala
##########
@@ -38,7 +38,11 @@ object MimaExcludes {
lazy val v31excludes = v30excludes ++ Seq(
// [SPARK-31077] Remove ChiSqSelector dependency on
mllib.ChiSqSelectorModel
// private constructor
-
ProblemFilters.exclude[IncompatibleMethTypeProblem]("org.apache.spark.ml.feature.ChiSqSelectorModel.this")
+
ProblemFilters.exclude[IncompatibleMethTypeProblem]("org.apache.spark.ml.feature.ChiSqSelectorModel.this"),
+ // [SPARK-31127] Implement abstract Selector
+
ProblemFilters.exclude[MissingTypesProblem]("org.apache.spark.ml.feature.ChiSqSelectorModel"),
Review comment:
The first two seem OK; that won't cause an actual source or binary
incompatibility (right?) just because there is an additional class in the
hierarchy.
The third one doesn't sound quite right. The type should be
ChiSqSelectorModel right? do you have to override it in the subclass like you
did with methods in ChiSqSelectorModel? the superclass returns this.type which
I thought was 'inherited' and would become ChiSqSelectorModel.
Am I right about that at all, and is there a workaround, or is MiMa
incorrect somehow and the type is concretely ChiSqSelectorModel? or is this
actually how lots of classes work?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
