Hi,

I've reviewed the current code again and I've come to the conclusion that
we should revert it completely. Here is an example of why I think it need
polishing:

public static void smaller(final long value, final long max, final String
message, final Object... values) {
   if (value >= max) {
      throw new IllegalArgumentException(String.format(message, values));
   }
}

while the double variant is implemented like this:

public static void smaller(final double value, final double max, final
String message, final Object... values) {
   if (!(value < max)) {
       throw new IllegalArgumentException(String.format(message, values));
   }
}

Why are two methods which do exactly the same implemented completely
different? I'm all smaller/greater methods. The (not)Non and (not)Finite
methods look good to me, so we can keep them.

Regards,
Benedikt

Pascal Schumacher <pascalschumac...@gmx.net> schrieb am So., 18. Sep. 2016
um 20:26 Uhr:

> Am 18.09.2016 um 13:58 schrieb Benedikt Ritter:
> > The problem with the current API is that we can't get rid of the "Object"
> > suffix:
> >
> > public static void different(long, long, String, Object...)
> > public static <T> void differentObject(T, T, String, Object...)
> >
> > when I change the second method name to "different" (or rename both to
> > notEquals), the method calls become ambiguous. This has something to do
> > with the varargs argument at the end.
> I would remove the (unreleased) primitive variants and reduce it to the
> object variant.
> > I'm currently not sure how to handle this. I'd rather like to release 3.5
> > without this API.
> +1 I think it's better to have a new release soon than having this hold
> up the release.
>
> -Pascal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Reply via email to