Fixing a minor bug in Number validation. #1329
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The function validateNumber only checks for numeric values. **By PHP isNumeric** "42", 1337, 0x539, 02471, 0b10100111001, 1337e0, "not numeric", array(), 9.1 **Will evaluate respectively** '42' is numeric '1337' is numeric '1337' is numeric '1337' is numeric '1337' is numeric '1337' is numeric 'not numeric' is NOT numeric 'Array' is NOT numeric '9.1' is numeric Grav though does not support all value types for a variety of reasons. One being YAML Blueprint definitions, where it makes sense to make a new type value for a more specialized format. Specifically for numbers if a more advance number format it would make sense to make a new type for that number format. YAML spec specifically allows both Integer or Float contexts, as seen in the validate class validateInt and validateFloat. This is useful when the output formats explicitly needs to be a certain format. However, in the case of generic numeric contexts, which numbers could be floats or ints dynamically, the values are cast back to an int currently in Grav numeric validation. Having dynamic primitive number formats is important, true in an interpreted language like JavaScript where 1 and 1.0 will both work for a number value. The reason to cast the type of the variable still is to prevent wide selection of number formats, and to keep Grav in line with primitive YAML field formats.
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The function validateNumber only checks for numeric values, regardless of int or float contexts.
By PHP isNumeric
"42",
1337,
0x539,
02471,
0b10100111001,
1337e0,
"not numeric",
array(),
9.1
Will evaluate respectively
'42' is numeric
'1337' is numeric
'1337' is numeric
'1337' is numeric
'1337' is numeric
'1337' is numeric
'not numeric' is NOT numeric
'Array' is NOT numeric
'9.1' is numeric
Grav though does not support all value types for a variety of reasons. One being YAML Blueprint definitions, where it makes sense to make a new type value for a more specialized format. Specifically for numbers if a more advance number format it would make sense to make a new type for that number format.
YAML spec specifically allows both Integer or Float contexts. As seen in Grav the validate class validateInt and validateFloat. This is useful when the output formats explicitly needs to be a certain format.
However, in the case of generic numeric contexts, which numbers could be floats or ints dynamically, the values are cast back to an int currently in Grav numeric validation. Having dynamic primitive number formats is important, true in an interpreted language like JavaScript where 1 and 1.0 will both work for a number value.
The reason to cast the type of the variable still is to prevent wide selection of number formats, and to keep Grav in line with primitive YAML field formats.