Refactored number parsing

[mpnovikova]

Simplified and refactored number parsing. All 117 unit tests are passing

[creationix]

Great work! Sorry I didn't see this sooner, I've been traveling for work.

The only question I have is do we want the new lenient behavior where it will parse invalid numbers without throwing an error? For example, try parsing "[12--e-e]". It will come out as [12]. Since all the number parsing states were merged into one, it will now accept nearly any combination of the allowed characters. The parseFloat builtin will simply parse till it hits an error and ignore the rest without throwing an error.

[mattsgarlata]

JSON.parse would throw an error in that case rather than accept the invalid number. It's nice to make things fault tolerant, but with JSON parsing being such a low level activity, it may make more sense to match the behavior of JSON.parse so there are no surprises.

[mpnovikova]

I replaced parseFloat() with Number()which for 12--e-e will yield NaN which should be inline with JSON.parse behavior. I am leaving the special check for the long string of digits because I need it for my project. It may not be kosher/orthodox JavaScript but it must work with Citrix for this project. Community may remove it if they want. However I would love it to stay there so I can keep this repo up to date. Instead of being stuck with one version I patched.

[mattsgarlata]

I had a thought. If someone needs to have an exception thrown you could perhaps compare things that come out as NaN and see if their original input was the String "NaN", and throw an exception in that case.

[mpnovikova]

@mattsgarlata Original NaN string won't make into this block it will be parsed as a string earlier. If NaN is received as a result of parsing a number charError will be returned like in the rest of the cases.

[mpnovikova]

@creationix would you mind bumping up a version on this repo so the npm install could pick it up? Thank you

[mattsgarlata]

OK @mpnovikova. I'm not really worried about this change, but thought I should bring up the exception handling in case anyone else had a strong opinion about it.

It certainly was impressive how much code you were able to remove in this pull request!

[mpnovikova]

Thank you!

Certainly a good point special Number values such as NaN, Infinity, MINIMUM_VALUE, and MAXIMUM_VALUE will be treated like strings but they are special numbers and should be treated as such.

[creationix]

@mpnovikova I believe your changes are in the latest release. Let me know if you need anything else.

[mpnovikova]

Thank you @creationix