Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <D94749EF-6C8B-40A8-B1CB-4E6F0CD409E0@gmail.com>
References: <0b4c82e96fcb4a49830913fadbd8c3ae@git.apache.org>
 <CAJZRQKw49dsbNU=yYFNAhDjxpaWeQHZJ1ErLgNcR3A26s2-sTQ@mail.gmail.com>
 <CAOGo0Vb7Z0YbGjwOk4e_-yPYRyAMiiZ_kp9mROeboh0bQSGSUw@mail.gmail.com>
 <CAJZRQKzhbyCwz9M3ykQR3c3+kGbNscJw5GLxbUS2VBj69aujjQ@mail.gmail.com>
 <4BE74B73-95CD-42F5-AE5A-8E7C6BC15624@gmail.com> <CAB917RKDykhpyHPnyoE792+aDRj14-rmGJZkFBbOSWWEQsDgag@mail.gmail.com>
 <D94749EF-6C8B-40A8-B1CB-4E6F0CD409E0@gmail.com>
From: Gary Gregory <garydgregory@gmail.com>
Date: Sat, 30 Jul 2016 09:41:01 -0700
Message-ID: <CACZkXPwCYM94vWEzn29cTCRaiAO9j6SDbYZBZBcGRtifcbEgVw@mail.gmail.com>
Subject: Re: [LANG] LANG-1252 - NumberUtils.isNumber and NumberUtils.createNumber
 resolve inconsistently
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001a11c1770a5230ea0538dd087b
archived-at: Sat, 30 Jul 2016 16:41:08 -0000

--001a11c1770a5230ea0538dd087b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Can this all be solved with better Javadocs?

Gary

On Jul 29, 2016 7:59 AM, "Rob Tompkins" <chtompki@gmail.com> wrote:

> Hi Benedikt,
>
> Thanks for the insights here.
>
> > On Jul 29, 2016, at 3:53 AM, Benedikt Ritter <britter@apache.org> wrote=
:
> >
> > Hello Rob,
> >
> > Rob Tompkins <chtompki@gmail.com <mailto:chtompki@gmail.com>> schrieb
> am Do., 28. Juli 2016 um
> > 14:23 Uhr:
> >
> >> In short, I=E2=80=99m trying to generalize LANG-1060, LANG-1040, LANG-=
1038, and
> >> LANG-992 with a single issue that actually hits all the bases here wit=
h
> >> NumberUtils.isNumber.
> >>
> >> Bug (1):
> >>
> >>        System.out.println(lang.math.NumberUtils.isNumber(=E2=80=9C+2=
=E2=80=9D)); ---->
> >> false
> >>
> >> while
> >>
> >>        System.out.println(lang.math.NumberUtils.createNumber(=E2=80=9C=
+2));
> ---->
> >> 2
> >>
> >> Bug (2):
> >>
> >>
> >>        System.out.println(lang.math.NumberUtils.isNumber(=E2=80=9C01.5=
=E2=80=9D)); ---->
> >> false
> >>
> >> while
> >>
> >>        System.out.println(lang.math.NumberUtils.createNumber(=E2=80=9C=
01.5));
> >> ----> 1.5.
> >>
> >>
> >>
> >> It seems to me that we could externalize a considerable amount of the
> code
> >> underlying the two methods into shared methods, as it seems like all t=
he
> >> validations in createNumber that predicate object creation should be
> >> directly used in isNumber. I would love to hear folks=E2=80=99 thought=
s.
> >>
> >
> > I think it is important to pay close attention to the JavaDocs in this
> case.
> >
> > NumberUtils.isNumber :
> > Checks whether the String a valid Java number.
> >
> > This has nothing to do with createNumber:
> > NumberUtils.createNumber: Turns a string value into a java.lang.Number
> >
> > What you're probably looking for is:
> >
> > NumberUtils.isParsebale: Checks whether the given String is a parsable
> > number.
> >
> > The difference is, that isNumber tells you, whether putting the given
> > String into Java code woul compile, while isParseble stells you whether=
 a
> > call to createNumber will be successful.
>
> This feels confusing to me (mainly because I=E2=80=99m not clear of the c=
ontext of
> the word =E2=80=9Ccompile=E2=80=9D here). But, I=E2=80=99m mostly agnosti=
c regarding intent here.
> So let=E2=80=99s not concern ourselves with that.
>
> Maybe the Jira issue that I created, LANG-1252, should just make the
> javadoc clearer in this case.
>
> Along the same line of thought, in NumberUtilsTest
>         testIsNumber()
> calls the function
> private void compareIsNumberWithCreateNumber(final String val, final
> boolean expected) {
>     final boolean isValid =3D NumberUtils.isNumber(val);
>     final boolean canCreate =3D checkCreateNumber(val);
>     if (isValid =3D=3D expected && canCreate =3D=3D expected) {
>         return;
>     }
>     fail("Expecting "+ expected + " for isNumber/createNumber using \"" +
> val + "\" but got " + isValid + " and " + canCreate);
> }
> where =E2=80=9CcheckCreateNumber=E2=80=9D is declared as:
> private boolean checkCreateNumber(final String val) {
>     try {
>         final Object obj =3D NumberUtils.createNumber(val);
>         if (obj =3D=3D null) {
>             return false;
>         }
>         return true;
>     } catch (final NumberFormatException e) {
>         return false;
>    }
> }
> which continues to puzzle me. If, indeed, it is the case that isNumber an=
d
> createNumber necessarily differ, might we also refactor the unit tests as
> part of LANG-1252 such that they aren=E2=80=99t directly correlated for t=
he sake of
> validation?
>
> Again, many thanks for the response here.
>
> Cheers,
> -Rob
>
> >
> > Regards,
> > Benedikt
> >
> >
> >> Cheers,
> >> -Rob
>
>

--001a11c1770a5230ea0538dd087b--