On 6 May 2014 18:43, Benedikt Ritter <brit...@apache.org> wrote: > 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)"
OK by me > >> >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
