Github user smurakozi commented on a diff in the pull request:
https://github.com/apache/spark/pull/19599#discussion_r156605360
--- Diff: mllib/src/main/scala/org/apache/spark/ml/param/params.scala ---
@@ -435,6 +435,43 @@ class BooleanParam(parent: String, name: String, doc:
String) // No need for isV
}
}
+/**
+ * :: DeveloperApi ::
+ * Specialized version of `Param[String]` for Java.
+ */
+@DeveloperApi
+class StringParam(parent: Params, name: String, doc: String, isValid:
String => Boolean)
+ extends Param[String](parent, name, doc, isValid) {
+
+ private var options: Option[Array[String]] = None
--- End diff --
What about this?
```
class StringParam(parent: Params, name: String, doc: String, isValid:
String => Boolean,
options: Option[Array[String]] = None)
extends Param[String](parent, name, doc, isValid) {
...
def this(parent: Params, name: String, doc: String, options:
Array[String]) = {
this(parent, name, doc + s" Supported options (case-insensitive):
${options.mkString(", ")}.",
s => options.exists(s.equalsIgnoreCase), Some(options))
}```
This solves the options as val problem, but highlights another one:
why do we need the possibility to give an explicit isValid? Why not always
expect options only?
I agree with @attilapiros that these params are enum-like. If so the only
reasonable validation is to check if one of the acceptable values are given
(ignoring case). I don't remember ever seeing a custom validator doing anything
else. Removing these custom validators would decrease complexity and code
duplication.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
