[ https://issues.apache.org/jira/browse/SPARK-16151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15344898#comment-15344898 ]
Sean Owen commented on SPARK-16151: ----------------------------------- Pardon, I don't follow the reasoning. If a param is final, it can't be overridden / specialized. If the motivation is documentation though -- why would you need to vary the javadoc for a param that can't be overridden? I can imagine some reasons, but you could doc these elsewhere, and doesn't seem like it should control the class design. > Make generated params non-final > ------------------------------- > > Key: SPARK-16151 > URL: https://issues.apache.org/jira/browse/SPARK-16151 > Project: Spark > Issue Type: Improvement > Components: MLlib > Affects Versions: 2.0.0 > Reporter: Xiangrui Meng > > Currently, all generated param instances are final. There are several > scenarios where we need them to be non-final: > 1. We don't have a guideline about where we should document the param doc. > Some were inherited from the generated param traits directly, while some were > documented in the setters if we want to make changes. I think it is better to > have all documented in the param instances, which appear at the top the > generated API doc. However, this requires inherit the param instance. > {code} > /** > * new doc > */ > val param: Param = super.param > {code} > We can use `@inherit_doc` if we just want to add a few words to the inherited > doc. > 2. We might want to update the embedded doc in the param instance. > Opened this JIRA for discussion. -- 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