Hmm... my main proposal seems to have gotten lost in the shuffle (sorry, couldn't resist).
Proposal: void reverse(type[] array) Becomes: type[] reverse(type[] array) The input array is returned. That's it. -- To follow the shuffle, this lets shuffle lie: ArrayUtils.cutTheDeck(ArrayUtils.shuffleHere(ArrayUtils.shuffleThere(deck))) ; Etc. Gary > -----Original Message----- > From: __matthewHawthorne [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 08, 2003 14:58 > To: Jakarta Commons Developers List > Subject: Re: [lang] ArrayUtils.reverse > > 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]
