On 5 May 2014 22:14, Benedikt Ritter <benerit...@gmail.com> wrote: > > >> Am 05.05.2014 um 22:20 schrieb sebb <seb...@gmail.com>: >> >>> On 5 May 2014 18:40, Benedikt Ritter <brit...@apache.org> wrote: >>> Hi, >>> >>> we have a pull request at github for [lang] which proposes to introduce new >>> methods in NumberUtils that take varargs as input parameters instead of >>> arrays [1]. I think a better solution would be to change those old methods >>> to use varargs instead of introducing new methods. Since I'm not sure how >>> this affects binary compatibility, I'd like to here what others thing about >>> this. >>> >>> Clirr doesn't even create an info for a change like this, so I'm assuming >>> it can be changed without affecting clients. >> >> In most cases, the effect is the same, but there are some edge cases >> according to >> >> http://stackoverflow.com/questions/5405673/java-varags-method-param-list-vs-array >> >> However, I don't like the proposed solution which needs new names. > > Yes, I don't like that either. > >> One way round this might be to extend the existing methods as follows: >> >> max(a,b,c,...) > > This would be a solution. But why not change max(a[]) to max(a...) if it is > binary compartible?
How can the compiler know whether max(1,2,3) is max(a,b,c) or max(a...) ? > The corner case mentioned in the stackoverflow article seems to be about > generic varargs parameters. Yes, it does seem to only affect code that would not have compiled previously. >> >> I think this was already done in some Commons code? > > I've had a brief look at StringUtils. There were some changes like this > documented by they happend to be implemented in 3.0, so I was unsure :-) > >> >>> Benedikt >>> >>> >>> [1] https://github.com/apache/commons-lang/pull/23 >>> >>> -- >>> http://people.apache.org/~britter/ >>> http://www.systemoutprintln.de/ >>> http://twitter.com/BenediktRitter >>> http://github.com/britter >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
