-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed opt/get Int/Long/Double inconsistencies #661
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. I think removal of the hexfloat is probably OK. It is not a standard in JSON anyway.
Possible problem with the unit tests? |
@stleary The test failures aren't from these changes, they must be there earlier too. For example, consider the following test case
The line What should be the behaviour with numbers in String format when providing through the constructor? |
Something must be incorrect with the changes in this PR. That test case is correct. |
@johnjaylward Testcase is correct. The line It's like instead of producing an array of |
I have fixed the issue with validating the String for numeric literals. Do we need to consider |
Modifying stringToNumber() may not be the best way to address this issue. The goal is for the get* and opt* methods to behave the same, while minimizing changes to existing behavior. |
As discussed here, this PR fixed the inconsistencies between get/opt Numbers