> Implementation thoughts:
> (1) Switch implementation “isNumber” -> “isParsable”
> (2) Deprecate “isNumber” and have it call “isParsable"
> (3) Rename “createNumber” to “parseNumber” (with Deprecation)
> (4) Fix subtle differences between “parseNumber” and newly implemented
> “isParsable"
> (5) Write “isJavaNumberLiteral” from beginning.
>
I took a look at the code. As far as design goes I think they are all good
improvements. I did notice this in the doc:
--
<p>Parsable numbers include those Strings understood by {@link
Integer#parseInt(String)},
* {@link Long#parseLong(String)}, {@link Float#parseFloat(String)} or
* {@link Double#parseDouble(String)}. This method can be used instead
of catching {@link java.text.ParseException}
* when calling one of those methods.</p>
<p>Hexadecimal and scientific notations are <strong>not</strong> considered
parsable.
--
So this makes me wonder if a method called isParsable should in fact be
able to parse these numbers? Is this doc canonical somehow, or just how
previous contributors chose to think about the issue? In which case the doc
could be restated, saying for example "Hexadecimal and scientific notations
are <strong>not</strong> considered Number Literals."
Regarding point 5, this page
https://en.wikibooks.org/wiki/Java_Programming/Literals
uses the term "Numeric Literal", perhaps that is better phrasing than
"Number Literal"?
Eric
