commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [QUESTION] Is switching from array parameter to varargs binary compatible?
Date Tue, 06 May 2014 23:17:52 GMT
On 6 May 2014 18:43, Benedikt Ritter <britter@apache.org> wrote:
> 2014-05-06 9:39 GMT+02:00 Benedikt Ritter <britter@apache.org>:
>
>>
>>
>> 2014-05-06 5:06 GMT+02:00 Julien Aymé <julien.ayme@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 <sebbaz@gmail.com>:
>>> > On 5 May 2014 22:14, Benedikt Ritter <beneritter@gmail.com> wrote:
>>> >>
>>> >>
>>> >>> Am 05.05.2014 um 22:20 schrieb sebb <sebbaz@gmail.com>:
>>> >>>
>>> >>>> On 5 May 2014 18:40, Benedikt Ritter <britter@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-unsubscribe@commons.apache.org
>>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> > For additional commands, e-mail: dev-help@commons.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message