Re: [lang] ArrayUtils.reverse

[__matthewHawthorne]

I don't see a need to deprecate the existing methods.  In methods such 
as reverse(Object[]), I think the default behavior would be to modify 
the argument.  That's the way that methods in java.util.Arrays as 
java.util.Collections behave.  However, as I've said, I think that 
reverseAsCopy versions for all of the reverse methods are acceptable, 
although I am starting to prefer reverseCopy as a name.  However, I hear 
what Stephen is saying about bloat...

For example, what if I were to propose an array version of:
- void java.util.Collections.shuffle(List list)
which would be:
- void ArrayUtils.shuffle(Object[] array)
and would possibly need:
- Object[] ArrayUtils.shuffleCopy(Object[] array)
Would this be accepted?  What about versions for all of the primitive 
types?

My hypothetical suggestion may be polluting the conversation, but I'm 
trying to paint a picture that forces us to decide if these types of 
methods are suitable for ArrayUtils, another class, or [lang] in general.

What do you think?



Gary Gregory wrote:

Here is a proposal that I think addresses all issues but I am not sure why
changing reverse() to return something instead of void is not backwards
compatible (granted you need to recompile). Are we saying that we want
binary compatibility. It seems ok to ask folks to recompile.
1) reverse does not change but is deprecated, in favor of:
2) new methods reverseShallow (as opposed to "deep") are just like reverse
and it returns its arg.
3) do not add reverseAsCopy until someone asks for it.
Thoughts?

Gary


-----Original Message-----
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 13:20
To: Jakarta Commons Developers List
Subject: Re: [lang] ArrayUtils.reverse
I would agree that reverse() should probably return the array, however
this
is a nasty backwards compatable change, seems harmless but actually messes
up anyone where two OSS projects require different versions of lang. (We
made some incompatble changes in 2.0, but I'm aiming to avoid these
entirely
now in such a low level library as lang) So I'm -1.
reverseCopy() sounds fine, however I would question how much of a need it
meets. We must be very challenging of new methods in lang to avoid too
much
bloat, without blocking everything. Its a fine line.
Stephen

----- Original Message -----
From: "Gary Gregory" <[EMAIL PROTECTED]>
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]

---------------------------------------------------------------------
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]