commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Herbert <alex.d.herb...@gmail.com>
Subject Re: [rng] binary compatibility with final modifier
Date Thu, 23 May 2019 12:51:20 GMT

On 23/05/2019 13:46, Gilles Sadowski wrote:
> Hello.
>
> Le jeu. 23 mai 2019 à 14:10, Alex Herbert <alex.d.herbert@gmail.com> a écrit
:
>>
>> On 23/05/2019 12:53, sebb wrote:
>>> Are the classes supposed to be final?
>>> Or just the existing constructor(s)?
>> The two package-private classes are definitely helper classes and should
>> be final.
>>
>> The class with the clirr issue (it is actually an info) only has static
>> methods. So currently it is a utility class.
>>
>> Changing it to have a new role with instance methods would be a design
>> update that could be served by introducing a new class. However this
>> class has taken the best name.
>>
>> Any instance role for the class would require that it is typed for
>> generics. But a quick try seems to pass clirr.
>>
>> Gilles, any opinion on a future for ListSampler as:
>>
>> public class ListSampler<T> {
>>
>>      // Other static stuff (already in the class)...
>>
>>      T sample();
>>
>> }
> Unless I'm missing something, this use-case is covered by
> "CollectionSampler".[1]
> "ListSampler" is for other use-cases (sublist, in-place shuffle).[2]
Yes. I missed that. So there is never a need for an instance of 
ListSampler and it can be made final without breaking any compatibility.
>
> Regards,
> Gilles
>
> [1] http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.2/org/apache/commons/rng/sampling/CollectionSampler.html
> [2] http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.2/org/apache/commons/rng/sampling/ListSampler.html
>
>> Alex
>>
>>
>>> On Thu, 23 May 2019 at 12:51, Gilles Sadowski <gilleseran@gmail.com> wrote:
>>>> Hello.
>>>>
>>>> Le jeu. 23 mai 2019 à 13:43, Alex Herbert <alex.d.herbert@gmail.com>
a écrit :
>>>>> [rng] has three classes with a private constructor that are not
>>>>> currently marked as final. 1 is public and 2 are package private.
>>>>>
>>>>> If I mark them as final then clirr:check ignores the package private
>>>>> ones and produces this warning for the public one:
>>>> If it's a "Warning" and not an "Error", I don't think that it could
>>>> count as a release blocker.  [Confirmation from PMC members
>>>> welcome...]
>>>>
>>>>> "Added final modifier to class, but class was effectively final anyway"
>>>>>
>>>>>
>>>>> Given the class could not have been extended (due to a private
>>>>> constructor) it seems OK to allow the final modifier.
>>>> I think so.
>>>>
>>>>> So can the final modifier be added? Is there a precedent here with
>>>>> regard to releases?
>>>> Cf. above.
>>>>
>>>> Gilles
>>>>
> ---------------------------------------------------------------------
> 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


Mime
View raw message