[ 
https://issues.apache.org/jira/browse/SPARK-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14662333#comment-14662333
 ] 

Bertrand Dechoux commented on SPARK-9720:
-----------------------------------------

I could take care of it.

Here is the list (only in spark.ml) :
* DecisionTreeClassificationModel
* DecisionTreeRegressionModel
* GBTClassificationModel
* GBTRegressionModel
* NaiveBayesModel
* RFormula
* RFormulaModel
* RandomForestClassificationModel
* RandomForestRegressionModel

The question is do we want to enforce that "identifiable types should be 
identifiable by their toString".
It does make sense. The following question is can we introduce potential API 
breaking change in the API in order to do it?

If the answer is yes, the easy way would be to set Identifiable.toString as 
final and compose it with an overridable empty suffix

private[spark] trait Identifiable {

  /**
   * An immutable unique ID for the object and its derivatives.
   */
  val uid: String
  
  def toStringSuffix: String = ""

  override final def toString: String = uid + toStringSuffix
}

Is there a committer that could validate this proposal?

> spark.ml Identifiable types should have UID in toString methods
> ---------------------------------------------------------------
>
>                 Key: SPARK-9720
>                 URL: https://issues.apache.org/jira/browse/SPARK-9720
>             Project: Spark
>          Issue Type: Improvement
>          Components: ML
>            Reporter: Joseph K. Bradley
>            Priority: Minor
>              Labels: starter
>
> It would be nice to print the UID (instance name) in toString methods.  
> That's the default behavior for Identifiable, but some types override the 
> default toString and do not print the UID.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to