I've not heard back on this last post. So... is my idea below not acceptable because it breaks the API signature for reverse? If not acceptable, would a new API be acceptable? Name to be suggested later this is the correct path...
Thank, Gary > -----Original Message----- > From: Gary Gregory [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 08, 2003 15:10 > To: 'Jakarta Commons Developers List' > Subject: RE: [lang] ArrayUtils.reverse > > 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]
