commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang] ArrayUtils.reverse
Date Wed, 08 Oct 2003 22:10:04 GMT
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:matth@phreaker.net]
> 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:scolebourne@btopenworld.com]
> >>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" <ggregory@seagullsw.com>
> >>
> >>>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:matth@phreaker.net]
> >>>>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-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message