From: "Gary Gregory" <[EMAIL PROTECTED]> > So from your POV, if I want an API just like the current reverse() with the > addition of the arg being returned, it has be a *new* API? Check? > > Do we want this new API? Am I SOL? Personally, no. It pushes beyond my lang gut-feel boundary.
> If we were to write a reverse API today without backwards compatibility in > mind with the functionality I desire, what would it look like? To have the chaining functionality, it would be Object[] reverse(Object[]). However, I believe that chaining should generally be avoided, and especially on static utility classes. It confuses the API, with users assuuming they need to assign the result. Stephen > > -----Original Message----- > > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 10, 2003 14:28 > > To: Jakarta Commons Developers List > > Subject: Re: [lang] ArrayUtils.reverse > > > > I'm -1 on changing the existing API because of binary compatability. > > I'm -0 on replacing it with the new one because I feel the void return > > makes > > it clear what is happening. > > > > Stephen > > > > ----- Original Message ----- > > From: "Gary Gregory" <[EMAIL PROTECTED]> > > To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]> > > Sent: Friday, October 10, 2003 9:54 PM > > Subject: RE: [lang] ArrayUtils.reverse > > > > > > > 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: commons-dev- > > [EMAIL PROTECTED] > > > > > >>>>For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > >>> > > > > > >> > > > > > > > >>--------------------------------------------------------------------- > > > > > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > >>For additional commands, e-mail: commons-dev- > > [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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
