[
https://issues.apache.org/jira/browse/HADOOP-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585227#action_12585227
]
Chris Douglas commented on HADOOP-3048:
---------------------------------------
bq. There is NO difference between X and Y except that the former is
encapsulated in a reusable, well documented utility function, that others can
freely use...
That said functionality is encapsulated in a reusable, well documented utility
function that others can freely use is the substance of my objection. I don't
think it's necessary and while the compiler (and Hudson) can flag an unchecked
cast and committers can spot-check for wanton (and uncommented)
SuppressWarnings annotations, less fastidious uses of GenericUtils functions
can slip in unnoted, unscrutinized, and unjustified. I fully agree with your
reasoning, but come to the opposite conclusion: that there is no difference
between the one line of code (that generates a warning that must be justified)
and a utility function in a new class recommends against the latter approach.
All that said, I can live with GenericsUtil if you remain convinced that it has
a role. Arguing against my self of three lines ago, most of its functionality
could also fit in ReflectionUtils, but the distinction couldn't matter less.
bq. On the issue about load/store methods being static or not, I can say that
having one or two-liner non-static functions will not hurt, but the static
versions are "convenience" methods (as stated before, their main usage will be
to store/load objects to/from the configuration, and there is no need to keep a
DefaultStringifier reference for a one-time operation.), thus I propose we
introduce both static and non-static versions.
OK. If you're going to leave the statics in, then you might as well drop the
instance methods (v6 instead of v7). If someone creates an instance and keeps
it around, you're right, they're probably dealing with volumes of data that
won't go into the configuration (we hope).
+1 for v6. Thanks for all your work- and rework- on this.
> Stringifier
> -----------
>
> Key: HADOOP-3048
> URL: https://issues.apache.org/jira/browse/HADOOP-3048
> Project: Hadoop Core
> Issue Type: New Feature
> Affects Versions: 0.17.0
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Priority: Blocker
> Fix For: 0.17.0
>
> Attachments: 3048-alt.patch, stringifier_v1.patch,
> stringifier_v2.patch, stringifier_v3.patch, stringifier_v4.patch,
> stringifier_v5.patch, stringifier_v6.patch, stringifier_v7.patch
>
>
> Storing arbitrary objects in the configuration has been discussed before in
> HADOOP-449 and HADOOP-1873. Although enabling such functionality has the risk
> of encouraging people to put big binary objects in the configuration, for
> some use cases passing objects to tasks is absolutely necessary.
> This issue will track the implementation of a Stringifier interface which
> stringifies and destringifies objects. Using this implementation, developers
> can store objects in the configuration and restore them later.
> Any thoughts ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
