[
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
