Re: [rng] binary compatibility with final modifier
On 23/05/2019 13:46, Gilles Sadowski wrote:
Hello.
Le jeu. 23 mai 2019 à 14:10, Alex Herbert 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 {
// 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 wrote:
Hello.
Le jeu. 23 mai 2019 à 13:43, Alex Herbert 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-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
Re: [rng] binary compatibility with final modifier
Hello.
Le jeu. 23 mai 2019 à 14:10, Alex Herbert 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 {
>
> // 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]
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 wrote:
> >> Hello.
> >>
> >> Le jeu. 23 mai 2019 à 13:43, Alex Herbert 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] binary compatibility with final modifier
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 {
// Other static stuff (already in the class)...
T sample();
}
Alex
On Thu, 23 May 2019 at 12:51, Gilles Sadowski wrote:
Hello.
Le jeu. 23 mai 2019 à 13:43, Alex Herbert 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-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
Re: [rng] binary compatibility with final modifier
Are the classes supposed to be final? Or just the existing constructor(s)? On Thu, 23 May 2019 at 12:51, Gilles Sadowski wrote: > > Hello. > > Le jeu. 23 mai 2019 à 13:43, Alex Herbert 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-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
Re: [rng] binary compatibility with final modifier
Hello. Le jeu. 23 mai 2019 à 13:43, Alex Herbert 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
