You can't do a resize method because the code won't know which way you want to go with it. For instance, if you ask it to resize(list, 10) and the list has 20 elements in it, does that mean that you want it to trim it back so that it only contains 10 elements? Or, does that mean that it's okay, because it already has at least 10 elements in it? So, I'm cool with having two methods here. One for shrinking and one for growing (if necessary).
+1 on not needing the ListUtils.copy() method, since the core API provides it. +1 on the obscurity of the merge() method. That doesn't sound like a common enough requirement to be on commons collections. -----Original Message----- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, July 03, 2006 12:13 PM To: Jakarta Commons Developers List Subject: Re: [collections] New methods On 7/3/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Some possible new methods for [collections] > > ListUtils.trimSize(List list, int size) > - trims list size to size if too large > > ListUtils.forceSize(List list, int size) > - trims list size to size if too large > - adds extra nulls to the list if its too small Would it be bad to just have the one method that both enlarged and shrunk? resize(LIst, int) or something? > ListUtils.copy(List,Object[]) > - copy a collection into an array java.util.Collection.toArray() ? > ListUtils.merge(List list, List defaultValues) > - replace any null values in list with the matching index in defaultValues Do you think this is something people will need often? Seems likely to be quite rare. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]