[
https://issues.apache.org/jira/browse/COLLECTIONS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526784
]
alanmehio edited comment on COLLECTIONS-223 at 9/12/07 6:09 AM:
-----------------------------------------------------------------
The backward compatibility is the big issue. We can have two methods with
different return type but according to the java lang spec at
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
the return type is not considered as part of the method signature so the two
method are similar ; hence we get compilation error
If some body wants to get back the input collection; it will be be obtained
since it is a reference type ( the input collection paramter)
example
ArrayList list = new ArrayList();
int size = list.size(); // size is 0
CollectionUtils.addAll(list, new String[] { "value1", "value2" });
size = list.size(); // size is 2
I think we should give an example in the API so that developers are aware
without making them to look at the source code for the commons-collections. The
example in the API will make them aware of retrieving the input
collection which is an implicit indicator of how the code being implemented
inside the
CollectionUtils.addAll
I can not see the big benefit of returning the input parameter instead of
retreiving it by reference. The only difference will be in sending an anonymous
object as in the case of CollectionUtils.addAll(new ArrayList(), new String[]
{ "value1", "value2" });
instead of the above mentioned example.
The backward compatibility is the biggest issue which will ruin a lot of
applications; please be aware of this issue
Regards,
Alan Mehio
London, UK
was (Author: alanmehio):
The backward compatibility is the big issue. We can have two methods with
different return type but according to <a
href="http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html"; >the
java lang spec </a>
<b>the return type is not considered as part of the method signature so the two
method are similar ; hence we get compilation error </b>
If some body wants to get back the input collection; it will be be obtained
since it is a reference type ( the input collection paramter)
example
<i>ArrayList list = new ArrayList();
int size = list.size(); // size is 0
CollectionUtils.addAll(list, new String[] { "value1", "value2" });
size = list.size(); // size is 2
</i>
I think we should give an example in the API so that developers are aware
without making them to look at the source code for the commons-collections. The
example in the API will make them aware of retrieving the input
collection which is an implicit indicator of how the code being implemented
inside the
CollectionUtils.addAll
I can not see the big benefit of returning the input parameter instead of
retreiving it by reference. The only difference will be in sending an anonymous
object as in the case of CollectionUtils.addAll(<b>new ArrayList()</b>, new
String[] { "value1", "value2" });
instead of the above mentioned example.
The backward compatibility is the biggest issue which will ruin a lot of
applications; please be aware of this issue
Regards,
Alan Mehio
London, UK
> CollectionUtils.addAll() methods should return the input collection
> -------------------------------------------------------------------
>
> Key: COLLECTIONS-223
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-223
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
> Affects Versions: 3.2
> Reporter: Vasily Ivanov
> Priority: Minor
> Fix For: 4.0
>
>
> Like MapUtils.putAll() method returns input map, CollectionUtils.addAll()
> methods should return the input collection.
> This will allow to init and populate collection at the same line:
> ArrayList inputs = (ArrayList) CollectionUtils.addAll(new ArrayList(), new
> String[] { "value1", "value2" });
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
