[SPARK-29363][MLLIB] Make o.a.s.regression.Regressor public

[zero323]

What changes were proposed in this pull request?

• Removal of private[ml] modifier from Regressor.
• Marking Regressor as @DeveloperApi.

Why are the changes needed?

Consistency with the rest of ML API as described in the corresponding JIRA ticket.

Does this PR introduce any user-facing change?

Yes, as described above.

How was this patch tested?

Existing tests.

[SparkQA]

Test build #111805 has finished for PR 26033 at commit dadf1a8.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[SparkQA]

Test build #111806 has finished for PR 26033 at commit 1f42e82.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[dongjoon-hyun]

For me, it looks reasonable because this makes Regressor and RegressionModel consistent in the same file.

cc @srowen , @viirya , @jiangxb1987

[viirya]

Beside consistency, is there any benefit?

[srowen]

Agree, I think this was an oversight.

[dongjoon-hyun]

Thank you for review, @srowen and @viirya .
Merged to master.

@viirya . This makes it as one of the official developer API at least.

[dongjoon-hyun]

Since SPARK-29363 is marked as an Improvement, I merged this to master only, @zero323 .

[viirya]

Ok. Sounds good. This is not a bug fix. I think we only need merging to master.

[zero323]

Since SPARK-29363 is marked as an Improvement, I merged this to master only, @zero323 .

Makes perfect sense @dongjoon-hyun, thank you!

[zero323]

Beside consistency, is there any benefit?

@viirya I believe there is (I tried to make this point in the linked JIRA, as well as somewhat related SPARK-29212), though I guess I am not that good in pointing that out.

Regressor and similarly positioned traits have very little purely technical value - from the point of view of simple composition they can be simply replaced by Prediction / PredictionModel, however, they provide very useful information about meaning of the types, that extend them.

Let's imagine for a moment I want to build ensemble learners. Clearly one for regression problem will expect different type of partial learners than one for classification problems:

class EnsembleRegressor extends Estimator[EnsembleRegressor] with ... {
  def setModels(learners: Array[Regressor]: this.type
  ...
}

class EnsembleClassifier extends Estimator[EnsembleClassifier] with ...  {
  def setModels(learners: Array[Classifier]): this.type
  ...
}

So having these traits public, allows users to write more precise code, without hacks, like putting 3rd party code in o.a.s.

Obviously benefits rather limited, as dynamic nature of DataFrame leaks all over the place, but at the same time there is no harm giving users more precise tools to express their intentions.

[zero323]

Thank you @dongjoon-hyun, @srowen, @viirya.