[CLI] Please review CLI-277

[Benedikt Ritter <br...@apache.org>]

Hi,

I’d like to have feedback for CLI-277 [1], especially whether it will affect BC. Clirr is happy with this changes, to I suppose it is fine to merge this?

Thank you,
Benedikt

[1] https://github.com/apache/commons-cli/pull/13 <https://github.com/apache/commons-cli/pull/13>

Re: [CLI] Please review CLI-277

[Simon Spero <se...@gmail.com>]

But BC, per initial response. I said I needed more coffee :)

On Wed, Jun 14, 2017 at 8:55 AM, Simon Spero <se...@gmail.com> wrote:

> Oops -I missed that the method was already generic. Need bigger
> tablet/more coffee / bigger caffeine tablet
>
>
> On Jun 14, 2017 8:46 AM, "Simon Spero" <se...@gmail.com> wrote:
>
> On Jun 14, 2017 4:28 AM, "Benedikt Ritter" <br...@apache.org> wrote:
>
> I’d like to have feedback for CLI-277 [1], especially whether it will
> affect BC. Clirr is happy with this changes, to I suppose it is fine to
> merge this?
>
> [1] https://github.com/apache/commons-cli/pull/13 <
> https://github.com/apache/commons-cli/pull/13>
>
>
> The changes look like they ought to be ok, but I need to  check on
> something that isn't a tablet.
>
> In general, going from raw to generic  is easy, since the type erasure are
> the same, but changing things once they are generic gets harder. As des
> Rivers et. al. (2007,2017) note:
>
> But, also bear in mind that there are severe constraints on how a type or
> method that already is generic can be compatibly evolved with respect to
> its type parameters (see the tables above). So if you plan to generify an
> API, remember that you only get one chance (release), to get it right. In
> particular, if you change a type in an API signature from the raw type "
> List" to "List<?>" or "List<Object>", you will be locked into that
> decision. The moral is that generifying an existing API is something that
> should be considered from the perspective of the API as a whole rather than
> piecemeal on a method-by-method or class-by-class basis.
>
>
> https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Turning_
> non-generic_types_and_methods_into_generic_ones
>
> These guidelines are one of the best reference sources for information on
> compatibility. Definitely more comprehensible than the JLS.
>
>
>

Re: [CLI] Please review CLI-277

[Simon Spero <se...@gmail.com>]

Oops -I missed that the method was already generic. Need bigger tablet/more
coffee / bigger caffeine tablet

On Jun 14, 2017 8:46 AM, "Simon Spero" <se...@gmail.com> wrote:

On Jun 14, 2017 4:28 AM, "Benedikt Ritter" <br...@apache.org> wrote:

I’d like to have feedback for CLI-277 [1], especially whether it will
affect BC. Clirr is happy with this changes, to I suppose it is fine to
merge this?

[1] https://github.com/apache/commons-cli/pull/13 <
https://github.com/apache/commons-cli/pull/13>


The changes look like they ought to be ok, but I need to  check on
something that isn't a tablet.

In general, going from raw to generic  is easy, since the type erasure are
the same, but changing things once they are generic gets harder. As des
Rivers et. al. (2007,2017) note:

But, also bear in mind that there are severe constraints on how a type or
method that already is generic can be compatibly evolved with respect to
its type parameters (see the tables above). So if you plan to generify an
API, remember that you only get one chance (release), to get it right. In
particular, if you change a type in an API signature from the raw type "List"
to "List<?>" or "List<Object>", you will be locked into that decision. The
moral is that generifying an existing API is something that should be
considered from the perspective of the API as a whole rather than piecemeal
on a method-by-method or class-by-class basis.


https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Turning_
non-generic_types_and_methods_into_generic_ones

These guidelines are one of the best reference sources for information on
compatibility. Definitely more comprehensible than the JLS.

[CLI] Please review CLI-277

[Simon Spero <se...@gmail.com>]

On Jun 14, 2017 4:28 AM, "Benedikt Ritter" <br...@apache.org> wrote:

I’d like to have feedback for CLI-277 [1], especially whether it will
affect BC. Clirr is happy with this changes, to I suppose it is fine to
merge this?

[1] https://github.com/apache/commons-cli/pull/13 <
https://github.com/apache/commons-cli/pull/13>


The changes look like they ought to be ok, but I need to  check on
something that isn't a tablet.

In general, going from raw to generic  is easy, since the type erasure are
the same, but changing things once they are generic gets harder. As des
Rivers et. al. (2007,2017) note:

But, also bear in mind that there are severe constraints on how a type or
method that already is generic can be compatibly evolved with respect to
its type parameters (see the tables above). So if you plan to generify an
API, remember that you only get one chance (release), to get it right. In
particular, if you change a type in an API signature from the raw type "List"
to "List<?>" or "List<Object>", you will be locked into that decision. The
moral is that generifying an existing API is something that should be
considered from the perspective of the API as a whole rather than piecemeal
on a method-by-method or class-by-class basis.


https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Turning_
non-generic_types_and_methods_into_generic_ones

These guidelines are one of the best reference sources for information on
compatibility. Definitely more comprehensible than the JLS.