> On Aug 18, 2016, at 3:10 AM, Jochen Wiedmann <jochen.wiedm...@gmail.com>
> wrote:
>
> On Tue, Aug 16, 2016 at 9:10 PM, Benedikt Ritter <brit...@apache.org> wrote:
>
>>>> On Jul 31, 2016, at 3:03 PM, Rob Tompkins <chtom...@gmail.com> wrote:
>
>>>> System.out.println(NumberUtils.isParsable("+2")); ----> false
>>>> System.out.println(NumberUtils.createNumber("+2")); ---> 2
>>> If I had to guess the cause of this discrepancy, I would think that we
>>> would want “isNumber(str)” and “isParsable(str)” to be as restrictive as
>>> Java 1.6 for the sake of compatibility, noting that “+2” only can be parsed
>>> to a Double or Float in Java 1.6. That said, I’m assuming that we want
>>> “createNumber(str)” to hit a wider range of strings for number
>>> instantiation.
>
> I suggest to consider the following:
>
> - Replace isParsable(String) with (or, add a new method)
> getParseableType(String), where the latter would return something like
> "UNPARSEABLE", "FLOAT", "DOUBLE", indicating the expected result
> type for createNumber(String).
Maybe something more along the lines of isParsable(String), returning true if
the string is parsable to any subclasses of java.lang.Number, and then as our
other method we would have something along the lines of
isParsable(String,class) returning true if we can parse to that specific
subclass of java.lang.Number.
Either way, should this work go under LANG-1252 or a different issue?
-Rob
>
> Jochen
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> 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
