[
https://issues.apache.org/jira/browse/COLLECTIONS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291253#comment-14291253
]
Gonçalo Marques edited comment on COLLECTIONS-550 at 1/25/15 8:28 PM:
----------------------------------------------------------------------
Hello,
The pull request has just been updated taking your comments into consideration.
Changes:
* A new {{IterableUtils}} class was created and the feature was moved into it
* Methods were renamed to {{toString()}}
* A {{toString(Iterable)}} method was created where we call each element's
{{toString()}}, use a default delimiter ({{,}}), default prefix({{\[}}) and
default suffix ({{\]}})
* The method was overloaded with another one that also receives a
{{Transformer}}, which will be used to fetch each element's {{String}}
representation. Default delimiter, prefix and suffix were also used here
* There is another overload where client code may additionally specify a
delimiter, prefix and suffix, along with the {{Transformer}}.
The unit tests that support the feature became kind of extensive, covering a
wide number of combinations in all three methods ({{IterableUtilsTest}}). I
think we should keep it this way in order to guarantee correctness, even if we
change just a single method in the future (overloaded or not).
About moving the already existing methods that work with {{Iterable}} into the
new {{IterableUtils}}, I think that it makes sense. There are already distinct
and specific {{*Utils}} classes for each separate case, and an {{Iterable}} is
definitely not a {{Collection}}. This refactor looks more suitable for a
dedicated JIRA. It will be disruptive in what matters to client code and it
will need a deprecation process.
Let me know your thoughts or if you have any other question/doubt/improvement
regarding this issue!
Cheers,
GM
was (Author: gonmarques):
Hello,
The pull request has just been updated taking your comments into consideration.
Changes:
* A new {{IterableUtils}} class was created and the feature was moved into it
* Methods were renamed to {{toString()}}
* A {{toString(Iterable)}} method was created where we call each element's
{{toString()}}, use a default delimiter ({{,}}), default prefix({{\[}}) and
default suffix ({{\]}})
* The method was overloaded with another one that also receives a
{{Transformer}}. Default delimiter, prefix and suffix were also used here
* There is another overload where client code may specify a specific delimiter,
prefix and suffix.
The unit tests that support the feature became kind of extensive, covering a
wide number of combinations in all three methods. I think we should keep it
this way in order to guarantee correctness, even if we change just a single
method in the future (overloaded or not).
About moving the already existing methods that work with {{Iterable}} into the
new {{IterableUtils}}, I think that it makes sense. There are already distinct
and specific {{*Utils}} classes for each separate case, and an {{Iterable}} is
definitely not a {{Collection}}. This refactor looks more suitable for a
dedicated JIRA. It will be disruptive in what matters to client code and it
will need a deprecation process.
Let me know your thoughts or if you have any other question/doubt/improvement
regarding this issue!
Cheers,
GM
> Provide a simple way for creating an arbitrary String representation of a
> given Iterable
> ----------------------------------------------------------------------------------------
>
> Key: COLLECTIONS-550
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-550
> Project: Commons Collections
> Issue Type: New Feature
> Components: Collection
> Affects Versions: 4.0
> Reporter: Gonçalo Marques
> Priority: Minor
> Labels: collection, util
>
> Create an utility method that returns an arbitrary {{String}} representation
> of a given {{Iterable}}, where for each {{Iterable}} element one may require
> a {{String}} representation that is different from the element's own
> {{toString()}} result.
> Additionally the client may also provide an optional delimiter, where the
> default one could be the common {{", "}}.
> The transformation of each {{Iterable}} element into an arbitrary {{String}}
> could be implemented by the means of a {{Transformer}}.
> Example (illustrative method in {{CollectionUtils}}):
> {code}
> static <C> String toString(Iterable<C> iterable, Transformer<C, String>
> transformer);
> {code}
> Consider the following illustrative class:
> {code}
> class SomeClass {
> private final String propertyOne;
> private final String propertyTwo;
> public SomeClass(String propertyOne, String propertyTwo) {
> this.propertyOne = propertyOne;
> this.propertyTwo = propertyTwo;
> }
> public String getPropertyOne() {
> return propertyOne;
> }
> public String getPropertyTwo() {
> return propertyTwo;
> }
> @Override
> public String toString() {
> return propertyOne;
> }
> }
> {code}
> One could transform an {{Iterable}} containing elements of type {{SomeClass}}
> into a client provided {{String}} representation by calling:
> {code}
> // list contains elements of type SomeClass
> String result = CollectionUtils.toString(list, new Transformer<SomeClass,
> String>() {
> @Override
> public String transform(SomeClass someClass) {
> return someClass.getPropertyTwo();
> }
> });
> // Will print "propertyTwoA, propertyTwoB"
> System.out.println(result);
> result = CollectionUtils.toString(list, new Transformer<SomeClass, String>() {
> @Override
> public String transform(SomeClass someClass) {
> return someClass.getPropertyOne() + someClass.getPropertyTwo();
> }
> });
> // Will print propertyOneApropertyTwoA, propertyOneBpropertyTwoB
> System.out.println(result);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
