I think I like it BUT the issue you raise is an orthogonal one.
(1) A method that returns void cannot be used in an expression, period.
Client can always ignore the return value and it does not cost the app
anything.
(2) Whether or not the array is twiddled in-place or not is a separate issue
and we are talking about a new API. So let's deal with both separately. For
a new API I see the following possibilities:
(2.1.1) reverseCopy(type array[])
Sorts with reverse.
(2.1.1) reverseAsCopy(type array[])
Sorts with reverse, a little better.
(2.2) copyReverse(type array[])
Makes copying the most prominent verb, not quite right IMHO.
(2.3) reverse(type array[], boolean copyFirst)
Barf.
Gary
> -----Original Message-----
> From: __matthewHawthorne [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 08, 2003 12:09
> To: Jakarta Commons Developers List
> Subject: Re: [lang] ArrayUtils.reverse
>
> I think it's a good idea, but I like method that returns void also,
> because it may save memory by modifying the input array.
>
> Maybe your suggested method should be renamed to:
>
> Object[] copyReverse(final Object[] array)
>
> and be modified to not operate on the argument, but instead create a
> copy of it and return the reverse of the copy.
>
> What do you think?
>
>
>
>
> Gary Gregory wrote:
>
> > Hello,
> >
> > How about returning the argument instead of void for these APIs such
> that
> > they can be used in expressions?
> >
> > Now ArrayUtils:
> >
> > public static void reverse(final Object[] array) {
> >
> > Proposal:
> >
> > public static Object[] reverse(final Object[] array) {
> >
> >
> > I ran into this with the Object[] version of the API but this applies to
> all
> > other ArrayUtils.reverse APIs.
> >
> > This change should backwards compatible with a recompile of client code.
> >
> > Thanks,
> > Gary
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
