[ https://issues.apache.org/jira/browse/HDFS-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13547621#comment-13547621 ]
Suresh Srinivas edited comment on HDFS-4352 at 1/9/13 4:31 AM: --------------------------------------------------------------- bq. We use the builder pattern in many other places, such as MiniDFSCluster#Builder, DFSTestUtil#Builder, and so forth. Please check my comment from earlier. The builder is useful when we 10 different constructor with various combinations of parameters. You can consolidate them into a single constructor by using a builder. I do not think that is the case here. I believe the link you posted above is along the similar lines. I have no problems with number of arguments to a method and I see no need for converting that into a builder. As I have stated in my earlier comments, what was clearly documented as parameters to a method was obfuscated by a class, with members having no javadoc what so ever. Further I also have commented why some comments and change made in this patch are not only unnecessary, it actually made the existing code worse. Further, the reason why I looked at this is, in my other change (HDFS-4363), I bumped into bunch of javadoc warnings introduced by this change. bq. Nicholas, when I said we could revert this, I was referring to this JIRA-- not to HDFS-4353. It seems very irregular to revert HDFS-4353 with no community discussion. I have hard time understanding the community discussion part. The way I read it, I thought you were okay with revert to. That said, Nicholas, I would have let Todd revert this change. I think this change is using builder in the wrong place. Reducing the number of arguments by replacing it with a class is a bad idea. That said, I would rather spend my energy on more constructive thing than arguing this out. was (Author: sureshms): bq. We use the builder pattern in many other places, such as MiniDFSCluster#Builder, DFSTestUtil#Builder, and so forth. Please check my comment from earlier. The builder is useful when we 10 different constructor with various combinations of parameters. You can consolidate them into a single constructor by using a builder. I do not think that is the case here. I believe the link you posted above is along the similar lines. I have no problems with number of arguments to a method and the need for converting that into a builder. As I have stated in my earlier comments, what was clearly documented as parameters to a method was obfuscated by a builder, with no document what so ever each of the members are for. Further I also have commented why some comments and change made there were not only unnecessary, it actually made the existing code worse. Further, the reason why I looked at this is, in my other change I bumped into bunch of javadoc warnings introduced by this change. bq. Nicholas, when I said we could revert this, I was referring to this JIRA-- not to HDFS-4353. It seems very irregular to revert HDFS-4353 with no community discussion. I have hard time understanding the community discussion part. The way I read it, I thought you were okay with revert to. That said, Nicholas, I would have let Todd revert this change. > Encapsulate arguments to BlockReaderFactory in a class > ------------------------------------------------------ > > Key: HDFS-4352 > URL: https://issues.apache.org/jira/browse/HDFS-4352 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: hdfs-client > Affects Versions: 2.0.3-alpha > Reporter: Colin Patrick McCabe > Attachments: 01b.patch, 01.patch > > > Encapsulate the arguments to BlockReaderFactory in a class to avoid having to > pass around 10+ arguments to a few different functions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira