2014-05-06 9:39 GMT+02:00 Benedikt Ritter <brit...@apache.org>: > > > 2014-05-06 5:06 GMT+02:00 Julien Aymé <julien.a...@gmail.com>: > > Hi, >> >> <snip> >> How can the compiler know whether max(1,2,3) is max(a,b,c) or max(a...) ? >> </snip> >> >> max(1,2,3) is compiled to max(a,b,c). The compiler will use the finer >> method instead of using the more generic one. >> >> This is used for example in logging frameworks: >> there are multiple methods: >> log(String message) >> log(String message, Object arg) >> log(String message, Object arg1, Object arg2) >> log(String message, Object...args) >> This is used as an optimization to avoid the cost of creating an array >> for each var args call. >> > > Fine, so do we agree that we change for example > > public static long max(long[]) to public static long max(long...) > while also preserving public static long max(long...) >
sorry, this should be "while also preserving public static long max(long, long, long)" > > We're not dealing with generic typed arrays and Clirr doesn't show an > error, so it seems safe to change this. > > Benedikt > > >> >> My 2 cents, >> Julien >> >> >> 2014-05-06 2:21 GMT+04:00 sebb <seb...@gmail.com>: >> > 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 >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
